1.2 单元测试的目标

1.2  The goal of unit testing

尽管单元测试有助于保持项目增长，但仅仅编写测试是不够的。写得不好的测试仍然会产生相同的结果。

Although unit testing helps maintain project growth, it’s not enough to just write tests. Badly written tests still result in the same picture.

如图1.2所示，糟糕的测试在一开始确实有助于减缓代码恶化：与完全没有测试的情况相比，开发速度的下降并不那么明显。但事情的宏伟计划并没有真正改变。这样的项目进入停滞阶段可能需要更长时间，但停滞仍然是不可避免的。

As shown in figure 1.2, bad tests do help to slow down code deterioration at the beginning: the decline in development speed is less prominent compared to the situation with no tests at all. But nothing really changes in the grand scheme of things. It might take longer for such a project to enter the stagnation phase, but stagnation is still inevitable.

请记住，并非所有测试都生而平等。其中一些很有价值，对整体软件质量有很大贡献。其他人没有。它们会发出错误警报，不会帮助您捕获回归错误，而且速度慢且难以维护。在不清楚它是否对项目有帮助的情况下，很容易陷入为了单元测试而编写单元测试的陷阱。

Remember, not all tests are created equal. Some of them are valuable and contribute a lot to overall software quality. Others don’t. They raise false alarms, don’t help you catch regression errors, and are slow and difficult to maintain. It’s easy to fall into the trap of writing unit tests for the sake of unit testing without a clear picture of whether it helps the project.

仅仅在项目中投入更多的测试是无法达到单元测试的目的的。您需要同时考虑测试的价值和维护成本。成本构成取决于在各种活动上花费的时间：

You can’t achieve the goal of unit testing by just throwing more tests at the project. You need to consider both the test’s value and its upkeep cost. The cost component is determined by the amount of time spent on various activities:

由于高昂的维护成本，很容易创建净值接近于零甚至为负的测试。为了实现可持续的项目增长，您必须专注于高质量的测试——这些是唯一值得保留在测试套件中的测试类型。

It’s easy to create tests whose net value is close to zero or even is negative due to high maintenance costs. To enable sustainable project growth, you have to exclusively focus on high-quality tests — those are the only type of tests that are worth keeping in the test suite.

学习如何区分好的和坏的单元测试是至关重要的。我在第 4 章中介绍了这个主题。

It’s crucial to learn how to differentiate between good and bad unit tests. I cover this topic in chapter 4.

1.3 使用覆盖率指标衡量测试套件质量

1.3  Using coverage metrics to measure test suite quality

第一个也是最常用的覆盖率指标是代码覆盖率，也称为测试覆盖率；见图 1.3。该指标显示至少一个测试执行的代码行数与生产代码库中总行数的比率。

The first and most-used coverage metric is code coverage, also known as test coverage; see figure 1.3. This metric shows the ratio of the number of code lines executed by at least one test and the total number of lines in the production code base.

让我们看一个例子来更好地理解它是如何工作的。下面的清单显示了一个IsStringLong方法和一个涵盖它的测试。

Let’s see an example to better understand how this works. The following listing shows an IsStringLong method and a test that covers it.

该方法判断作为输入参数提供给它的字符串是否为长字符串（这里，长的定义是长度大于五个字符的任何字符串）。该测试使用该方法进行测试"abc"，并检查该字符串是否被认为不长。

The method determines whether a string provided to it as an input parameter is long (here, the definition of long is any string with the length greater than five characters). The test exercises the method using "abc" and checks that this string is not considered long.

public static bool IsStringLong（字符串输入）
{                           ❶ 
    if (input.Length > 5)   ❶
        返回真；        ❷

    返回假；           ❶ 
}                           ❶

公共无效测试（）
{
    布尔结果 = IsStringLong("abc");
    断言。等于（假，结果）；
}

public static bool IsStringLong(string input)
{                           ❶
    if (input.Length > 5)   ❶
        return true;        ❷

    return false;           ❶
}                           ❶

public void Test()
{
    bool result = IsStringLong("abc");
    Assert.Equal(false, result);
}

这里很容易计算代码覆盖率。方法中的总行数是五行（大括号也算在内）。测试执行的行数为四——测试遍历除语句之外的所有代码行return true;。这给了我们 4/5 = 0.8 = 80% 的代码覆盖率。

It’s easy to calculate the code coverage here. The total number of lines in the method is five (curly braces count, too). The number of lines executed by the test is four — the test goes through all the code lines except for the return true; statement. This gives us 4/5 = 0.8 = 80% code coverage.

现在，如果我像这样重构方法并内联不必要的if语句会怎样？

Now, what if I refactor the method and inline the unnecessary if statement, like this?

public static bool IsStringLong（字符串输入）
{
    返回输入。长度 > 5;
}

公共无效测试（）
{
    布尔结果 = IsStringLong("abc");
    断言。等于（假，结果）；
}

public static bool IsStringLong(string input)
{
    return input.Length > 5;
}

public void Test()
{
    bool result = IsStringLong("abc");
    Assert.Equal(false, result);
}

代码覆盖数是否改变？是的，它确实。因为测试现在运行了所有三行代码（return语句加上两个大括号），所以代码覆盖率增加到 100%。

Does the code-coverage number change? Yes, it does. Because the test now exercises all three lines of code (the return statement plus two curly braces), the code coverage increases to 100%.

但是我是否通过这种重构改进了测试套件？当然不是。我只是改组了方法中的代码。该测试仍然验证相同数量的可能结果。

But did I improve the test suite with this refactoring? Of course not. I just shuffled the code inside the method. The test still verifies the same number of possible outcomes.

这个简单的例子展示了玩弄覆盖数字是多么容易。您的代码越紧凑，测试覆盖率指标就越好，因为它只考虑原始行号。同时，将更多代码压缩到更少空间不会（也不应该）改变测试套件的价值或底层代码库的可维护性。

This simple example shows how easy it is to game the coverage numbers. The more compact your code is, the better the test coverage metric becomes, because it only accounts for the raw line numbers. At the same time, squashing more code into less space doesn’t (and shouldn’t) change the value of the test suite or the maintainability of the underlying code base.

另一个覆盖率指标称为分支覆盖率。分支覆盖比代码覆盖提供更精确的结果，因为它有助于应对代码覆盖的缺点。该指标没有使用代码行的原始数量，而是侧重于控制结构，例如if和switch语句。它显示了套件中至少有一个测试遍历了多少这样的控制结构，如图 1.4 所示。

Another coverage metric is called branch coverage. Branch coverage provides more precise results than code coverage because it helps cope with code coverage’s shortcomings. Instead of using the raw number of code lines, this metric focuses on control structures, such as if and switch statements. It shows how many of such control structures are traversed by at least one test in the suite, as shown in figure 1.4.

要计算分支覆盖率指标，您需要汇总代码库中所有可能的分支，并查看测试访问了其中的多少分支。让我们再次以我们之前的例子为例：

To calculate the branch coverage metric, you need to sum up all possible branches in your code base and see how many of them are visited by tests. Let’s take our previous example again:

public static bool IsStringLong（字符串输入）
{
    返回输入。长度 > 5;
}

公共无效测试（）
{
    布尔结果 = IsStringLong("abc");
    断言。等于（假，结果）；
}

public static bool IsStringLong(string input)
{
    return input.Length > 5;
}

public void Test()
{
    bool result = IsStringLong("abc");
    Assert.Equal(false, result);
}

该方法有两个分支IsStringLong：一个用于字符串参数的长度大于五个字符的情况，另一个用于不大于五个字符的情况。测试仅覆盖其中一个分支，因此分支覆盖率指标为 1/2 = 0.5 = 50%。我们如何表示被测代码并不重要——我们是if像以前一样使用语句还是使用更短的表示法。分支覆盖率指标仅考虑分支数量；它没有考虑实现这些分支需要多少行代码。

There are two branches in the IsStringLong method: one for the situation when the length of the string argument is greater than five characters, and the other one when it’s not. The test covers only one of these branches, so the branch coverage metric is 1/2 = 0.5 = 50%. And it doesn’t matter how we represent the code under test — whether we use an if statement as before or use the shorter notation. The branch coverage metric only accounts for the number of branches; it doesn’t take into consideration how many lines of code it took to implement those branches.

图1.3显示了一种可视化此指标的有用方法。您可以将被测代码可以采用的所有可能路径表示为图形，并查看其中有多少已被遍历。IsStringLong有两条这样的路径，测试只练习其中一条。

Figure 1.3 shows a helpful way to visualize this metric. You can represent all possible paths the code under test can take as a graph and see how many of them have been traversed. IsStringLong has two such paths, and the test exercises only one of them.

虽然分支覆盖率指标比代码覆盖率产生更好的结果，但您仍然不能依赖它们中的任何一个来确定测试套件的质量，原因有两个：

Although the branch coverage metric yields better results than code coverage, you still can’t rely on either of them to determine the quality of your test suite, for two reasons:

让我们更仔细地看看这些原因中的每一个。

Let’s look more closely at each of these reasons.

公共静态布尔 WasLastStringLong { 得到; 私有集；}

public static bool IsStringLong（字符串输入）
{
    bool result = input.Length > 5;
    WasLastStringLong = 结果；    ❶
    返回结果；                 ❷
}

公共无效测试（）
{
    布尔结果 = IsStringLong("abc");
    断言。等于（假，结果）；   ❸ 
}

public static bool WasLastStringLong { get; private set; }

public static bool IsStringLong(string input)
{
    bool result = input.Length > 5;
    WasLastStringLong = result;    ❶
    return result;                 ❷
}

public void Test()
{
    bool result = IsStringLong("abc");
    Assert.Equal(false, result);   ❸
}

公共无效测试（）
{
    bool result1 = IsStringLong("abc");      ❶ 
    bool result2 = IsStringLong("abcdef");   ❷ 
}

public void Test()
{
    bool result1 = IsStringLong("abc");      ❶
    bool result2 = IsStringLong("abcdef");   ❷
}

public static int Parse(字符串输入)
{
    返回 int.Parse(输入);
}

公共无效测试（）
{
    int result = Parse("5");
    Assert.Equal(5, 结果);
}

public static int Parse(string input)
{
    return int.Parse(input);
}

public void Test()
{
    int result = Parse("5");
    Assert.Equal(5, result);
}

在这一点上，我希望您能看到依靠覆盖率指标来确定测试套件的质量是不够的。如果您开始将特定的覆盖率数字作为目标，无论是 100%、90% 还是适度的 70%，它也可能导致危险区域。查看覆盖率指标的最佳方式是将其作为指标，而不是目标本身。

At this point, I hope you can see that relying on coverage metrics to determine the quality of your test suite is not enough. It can also lead to dangerous territory if you start making a specific coverage number a target, be it 100%, 90%, or even a moderate 70%. The best way to view a coverage metric is as an indicator, not a goal in and of itself.

想想医院里的病人。他们的高温可能表明发烧，这是一个有用的观察。但是医院不应该以任何必要的方式将这名患者的适当体温作为目标。否则，医院最终可能会采取快速“有效”的解决方案，即在患者旁边安装空调，并通过调节流到患者皮肤上的冷空气量来调节体温。当然，这种做法没有任何意义。

Think of a patient in a hospital. Their high temperature might indicate a fever and is a helpful observation. But the hospital shouldn’t make the proper temperature of this patient a goal to target by any means necessary. Otherwise, the hospital might end up with the quick and "efficient" solution of installing an air conditioner next to the patient and regulating their temperature by adjusting the amount of cold air flowing onto their skin. Of course, this approach doesn’t make any sense.

同样，以特定的覆盖率数字为目标会产生违背单元测试目标的不当激励。人们开始寻找实现这个人为目标的方法，而不是专注于测试重要的事情。正确的单元测试已经够困难了。强加一个强制性的覆盖率数字只会分散开发人员对他们测试内容的注意力，并使正确的单元测试更难实现。

Likewise, targeting a specific coverage number creates a perverse incentive that goes against the goal of unit testing. Instead of focusing on testing the things that matter, people start to seek ways to attain this artificial target. Proper unit testing is difficult enough already. Imposing a mandatory coverage number only distracts developers from being mindful about what they test, and makes proper unit testing even harder to achieve.

	提示
	对系统的核心部分进行高水平覆盖是件好事。将这种高水平作为要求是很糟糕的。差异很微妙，但很关键。 It’s good to have a high level of coverage in core parts of your system. It’s bad to make this high level a requirement. The difference is subtle but critical.

让我重复一遍：覆盖率指标是一个很好的负面指标，但却是一个糟糕的正面指标。低覆盖率数字——比如，低于 60%——是麻烦的某种迹象。它们意味着您的代码库中有很多未经测试的代码。但高数字并不意味着什么。因此，测量代码覆盖率应该只是通往高质量测试套件的第一步。

Let me repeat myself: coverage metrics are a good negative indicator, but a bad positive one. Low coverage numbers — say, below 60% — are a certain sign of trouble. They mean there’s a lot of untested code in your code base. But high numbers don’t mean anything. Thus, measuring the code coverage should be only a first step on the way to a quality test suite.

1.4 什么是成功的测试套件？

1.4  What makes a successful test suite?

• 它已集成到开发周期中。

• It’s integrated into the development cycle.

• 它只针对代码库中最重要的部分。

• It targets only the most important parts of your code base.

• 它以最低的维护成本提供最大的价值。

• It provides maximum value with minimum maintenance costs.

进行自动化测试的唯一要点是您是否经常使用它们。所有测试都应集成到开发周期中。理想情况下，您应该在每次代码更改时执行它们，即使是最小的代码更改。

The only point in having automated tests is if you constantly use them. All tests should be integrated into the development cycle. Ideally, you should execute them on every code change, even the smallest one.

正如并非所有测试都一样，就单元测试而言，并非代码库的所有部分都值得同等关注。测试提供的价值不仅在于这些测试本身的结构，还在于它们验证的代码。

Just as all tests are not created equal, not all parts of your code base are worth the same attention in terms of unit testing. The value the tests provide is not only in how those tests themselves are structured, but also in the code they verify.

重要的是将您的单元测试工作指向系统的最关键部分，而仅简要或间接地验证其他部分。在大多数应用程序中，最重要的部分是包含业务逻辑的部分——领域模型。^[1]测试业务逻辑可为您的时间投资带来最佳回报。

It’s important to direct your unit testing efforts to the most critical parts of the system and verify the others only briefly or indirectly. In most applications, the most important part is the part that contains business logic — the domain model.^[1] Testing business logic gives you the best return on your time investment.

所有其他部分可以分为三类：

All other parts can be divided into three categories:

不过，其中一些其他部分可能仍需要彻底的单元测试。例如，基础设施代码可能包含复杂而重要的算法，因此用大量测试覆盖它们也是有意义的。但一般来说，你的大部分注意力应该花在领域模型上。

Some of these other parts may still need thorough unit testing, though. For example, the infrastructure code may contain complex and important algorithms, so it would make sense to cover them with a lot of tests, too. But in general, most of your attention should be spent on the domain model.

您的一些测试（例如集成测试）可以超越域模型并验证系统作为一个整体的工作方式，包括代码库的非关键部分。这很好。但重点应该放在领域模型上。

Some of your tests, such as integration tests, can go beyond the domain model and verify how the system works as a whole, including the noncritical parts of the code base. And that’s fine. But the focus should remain on the domain model.

请注意，为了遵循此准则，您应该将领域模型与代码库的非必要部分隔离开来。您必须将域模型与所有其他应用程序问题分开，以便您可以将单元测试工作专门集中在该域模型上。我们将在本书的第 2 部分详细讨论所有这些内容。

Note that in order to follow this guideline, you should isolate the domain model from the non-essential parts of the code base. You have to keep the domain model separated from all other application concerns so you can focus your unit testing efforts on that domain model exclusively. We talk about all this in detail in part 2 of the book.

单元测试最困难的部分是以最小的维护成本实现最大价值。这是本书的主要关注点。

The most difficult part of unit testing is achieving maximum value with minimum maintenance costs. That’s the main focus of this book.

将测试合并到构建系统中是不够的，并且维持域模型的高测试覆盖率也是不够的。仅在套件中保留价值大大超过维护成本的测试也很重要。

It’s not enough to incorporate tests into a build system, and it’s not enough to maintain high test coverage of the domain model. It’s also crucial to keep in the suite only the tests whose value exceeds their upkeep costs by a good margin.

最后一个属性可以分为两个：

This last attribute can be divided in two:

尽管这些技能看起来很相似，但它们本质上是不同的。要识别高价值的测试，您需要一个参考框架。另一方面，编写有价值的测试还需要您了解代码设计技术。单元测试和底层代码高度交织在一起，如果不对它们所涵盖的代码库投入大量精力，就不可能创建有价值的测试。

Although these skills may seem similar, they’re different by nature. To recognize a test of high value, you need a frame of reference. On the other hand, writing a valuable test requires you to also know code design techniques. Unit tests and the underlying code are highly intertwined, and it’s impossible to create valuable tests without putting significant effort into the code base they cover.

您可以将其视为识别一首好歌曲和能够创作一首好歌曲之间的区别。成为作曲家所需要付出的努力，要比区分音乐好坏所需要付出的努力多得不对称。单元测试也是如此。编写新测试比检查现有测试需要更多的努力，主要是因为您不是在真空中编写测试：您必须考虑底层代码。因此，虽然我专注于单元测试，但我也将本书的重要部分用于讨论代码设计。

You can view it as the difference between recognizing a good song and being able to compose one. The amount of effort required to become a composer is asymmetrically larger than the effort required to differentiate between good and bad music. The same is true for unit tests. Writing a new test requires more effort than examining an existing one, mostly because you don’t write tests in a vacuum: you have to take into account the underlying code. And so although I focus on unit tests, I also devote a significant portion of this book to discussing code design.

1.5 本书内容

1.5  What you will learn in this book

• 如何重构测试套件及其涵盖的生产代码

• How to refactor the test suite along with the production code it covers

• 如何应用不同风格的单元测试

• How to apply different styles of unit testing

• 使用集成测试来验证整个系统的行为

• Using integration tests to verify the behavior of the system as a whole

• 识别和避免单元测试中的反模式

• Identifying and avoiding anti-patterns in unit tests

1.6 总结

1.6  Summary

• 代码趋于恶化。每次您更改代码库中的某些内容时，其中的混乱程度或熵都会增加。如果没有适当的照顾，例如不断的清理和重构，系统就会变得越来越复杂和混乱。测试有助于推翻这种趋势。它们充当安全网——一种为绝大多数回归提供保险的工具。

• Code tends to deteriorate. Each time you change something in a code base, the amount of disorder in it, or entropy, increases. Without proper care, such as constant cleaning and refactoring, the system becomes increasingly complex and disorganized. Tests help overturn this tendency. They act as a safety net —  a tool that provides insurance against the vast majority of regressions.

• 编写单元测试很重要。编写好的单元测试同样重要。测试不佳或没有测试的项目的最终结果是相同的：每个新版本要么停滞不前，要么出现大量倒退。

• It’s important to write unit tests. It’s equally important to write good unit tests. The end result for projects with bad tests or no tests is the same: either stagnation or a lot of regressions with every new release.

• 单元测试的目标是使软件项目可持续发展。一个好的单元测试套件有助于避免停滞阶段并随着时间的推移保持开发速度。有了这样的套件，您就可以确信您的更改不会导致性能下降。反过来，这使得重构代码或添加新功能变得更加容易。

• The goal of unit testing is to enable sustainable growth of the software project. A good unit test suite helps avoid the stagnation phase and maintain the development pace over time. With such a suite, you’re confident that your changes won’t lead to regressions. This, in turn, makes it easier to refactor the code or add new features.

• 并非所有测试都是平等的。每项测试都有成本和收益组成部分，您需要仔细权衡其中一项。只在套件中保留正净值的测试，并摆脱所有其他测试。应用代码和测试代码都是负债，不是资产。

• All tests are not created equal. Each test has a cost and a benefit component, and you need to carefully weigh one against the other. Keep only tests of positive net value in the suite, and get rid of all others. Both the application code and the test code are liabilities, not assets.

• 单元测试代码的能力是一个很好的试金石，但它只在一个方向上起作用。这是一个很好的负面指标（如果你不能对代码进行单元测试，那么它的质量很差）但是一个不好的正面指标（对代码进行单元测试的能力并不能保证它的质量）。

• The ability to unit test code is a good litmus test, but it only works in one direction. It’s a good negative indicator (if you can’t unit test the code, it’s of poor quality) but a bad positive one (the ability to unit test the code doesn’t guarantee its quality).

• 同样，覆盖率指标是一个很好的负面指标，但不是一个积极的指标。低覆盖率数字是麻烦的某种迹象，但高覆盖率数字并不自动意味着您的测试套件是高质量的。

• Likewise, coverage metrics are a good negative indicator but a bad positive one. Low coverage numbers are a certain sign of trouble, but a high coverage number doesn’t automatically mean your test suite is of high quality.

• 分支覆盖率可以更好地了解测试套件的完整性，但仍然不能表明套件是否足够好。它不考虑断言的存在，也不考虑您的代码库使用的第三方库中的代码路径。

• Branch coverage provides better insight into the completeness of the test suite but still can’t indicate whether the suite is good enough. It doesn’t take into account the presence of assertions, and it can’t account for code paths in third-party libraries that your code base uses.

• 强加一个特定的覆盖范围数字会产生不正当的激励。对系统的核心部分进行高水平的覆盖是件好事，但将这种高水平作为要求是不好的。

• Imposing a particular coverage number creates a perverse incentive. It’s good to have a high level of coverage in core parts of your system, but it’s bad to make this high level a requirement.

• 一个成功的测试套件具有以下属性：

  • 它被集成到开发周期中。

  • 它只针对代码库中最重要的部分。

  • 它以最低的维护成本提供最大的价值。

• A successful test suite exhibits the following attributes:

  • It is integrated into the development cycle.

  • It targets only the most important parts of your code base.

  • It provides maximum value with minimum maintenance costs.

• 实现单元测试目标（即实现可持续的项目增长）的唯一方法是

  • 学习如何区分好的和坏的测试。

  • 能够重构测试以使其更有价值。

• The only way to achieve the goal of unit testing (that is, enabling sustainable project growth) is to

  • Learn how to differentiate between a good and a bad test.

  • Be able to refactor a test to make it more valuable.

2.2 经典的和伦敦的单元测试学派

2.2  The classical and London schools of unit testing

• 隔离要求

• The isolation requirement

• 什么构成一段被测代码（一个单元）

• What constitutes a piece of code under test (a unit)

• 处理依赖关系

• Handling dependencies

表 2.1。伦敦单元测试学派和经典单元测试学派之间的差异，总结为隔离方法、单元的大小和测试替身的使用

Table 2.1. The differences between the London and classical schools of unit testing, summed up by the approach to isolation, the size of a unit, and the use of test doubles

请注意，尽管测试替身的使用无处不在，但伦敦学校仍然允许在测试中按原样使用某些依赖项。这里的试金石是依赖项是否可变。最好不要替换永远不会改变的对象—— 不可变对象。

Note that despite the ubiquitous use of test doubles, the London school still allows for using some dependencies in tests as is. The litmus test here is whether a dependency is mutable. It’s fine not to substitute objects that don’t ever change — immutable objects.

你在前面的例子中看到，当我将测试重构为伦敦风格时，我没有用Product模拟替换实例，而是使用了真实的对象，如以下代码所示（为方便起见，重复了清单2.2 ） :

And you saw in the earlier examples that, when I refactored the tests toward the London style, I didn’t replace the Product instances with mocks but rather used the real objects, as shown in the following code (repeated from listing 2.2 for your convenience):

[事实]
public void Purchase_fails_when_not_enough_inventory()
{
    // 安排
    var storeMock = new Mock<IStore>();
    storeMock
        .Setup(x => x.HasEnoughInventory(Product.Shampoo, 5))
        .返回（假）；
    var customer = new Customer();

    // 行为
    bool success = customer.Purchase(storeMock.Object, Product.Shampoo, 5);

    //断言
    断言.False(成功);
    storeMock.验证（
        x => x.RemoveInventory(Product.Shampoo, 5),
        次。从不）；
}

[Fact]
public void Purchase_fails_when_not_enough_inventory()
{
    // Arrange
    var storeMock = new Mock<IStore>();
    storeMock
        .Setup(x => x.HasEnoughInventory(Product.Shampoo, 5))
        .Returns(false);
    var customer = new Customer();

    // Act
    bool success = customer.Purchase(storeMock.Object, Product.Shampoo, 5);

    // Assert
    Assert.False(success);
    storeMock.Verify(
        x => x.RemoveInventory(Product.Shampoo, 5),
        Times.Never);
}

在 的两个依赖项中Customer，仅Store包含一个可以随时间变化的内部状态。实例Product是不可变的（Product它本身是一个 C# 枚举）。因此我Store只替换了实例。

Of the two dependencies of Customer, only Store contains an internal state that can change over time. The Product instances are immutable (Product itself is a C# enum). Hence I substituted the Store instance only.

如果您考虑一下，这是有道理的。5您也不会在之前的测试中对数字使用测试替身，对吗？那是因为它也是不可变的——你不可能修改这个数字。请注意，我不是在谈论包含数字的变量，而是数字本身。在语句中RemoveInventory(Product.Shampoo, 5)，我们甚至不使用变量；5立即宣布。对于 也是如此Product.Shampoo。

It makes sense, if you think about it. You wouldn’t use a test double for the 5 number in the previous test either, would you? That’s because it is also immutable — you can’t possibly modify this number. Note that I’m not talking about a variable containing the number, but rather the number itself. In the statement RemoveInventory(Product.Shampoo, 5), we don’t even use a variable; 5 is declared right away. The same is true for Product.Shampoo.

这种不可变对象称为值对象或值。他们的主要特点是没有个人身份；它们仅通过其内容来识别。作为必然结果，如果两个这样的对象具有相同的内容，那么您正在使用它们中的哪一个并不重要：这些实例是可以互换的。例如，如果你有两个5整数，你可以用它们代替另一个。我们案例中的产品也是如此：您可以重用单个Product.Shampoo实例或声明其中的多个实例——这不会有任何区别。这些实例将具有相同的内容，因此可以互换使用。

Such immutable objects are called value objects or values. Their main trait is that they have no individual identity; they are identified solely by their content. As a corollary, if two such objects have the same content, it doesn’t matter which of them you’re working with: these instances are interchangeable. For example, if you’ve got two 5 integers, you can use them in place of one another. The same is true for the products in our case: you can reuse a single Product.Shampoo instance or declare several of them — it won’t make any difference. These instances will have the same content and thus can be used interchangeably.

请注意，值对象的概念与语言无关，不需要特定的编程语言或框架。您可以在我的文章“实体与值对象：差异的最终列表”中阅读更多关于值对象的信息，网址为http://mng.bz/KE9O。

Note that the concept of a value object is language-agnostic and doesn’t require a particular programming language or framework. You can read more about value objects in my article "Entity vs. Value Object: the ultimate list of differences" at http://mng.bz/KE9O.

图2.4显示了依赖关系的分类以及两种单元测试流派如何对待它们。依赖项可以是shared或private。反过来，私有依赖项可以是可变的或不可变的。在后一种情况下，它被称为值对象。例如，数据库是一个共享的依赖项——它的内部状态在所有自动化测试中共享（不会用测试替身替换它）。实例是可变的私有依赖项。和一个实例（或一个数字的实例StoreProduct5，就此而言）是一个不可变的私有依赖的例子——一个值对象。所有共享的依赖项都是可变的，但是要共享一个可变的依赖项，它必须被测试重用。

Figure 2.4 shows the categorization of dependencies and how both schools of unit testing treat them. A dependency can be either shared or private. A private dependency, in turn, can be either mutable or immutable. In the latter case, it is called a value object. For example, a database is a shared dependency — its internal state is shared across all automated tests (that don’t replace it with a test double). A Store instance is a private dependency that is mutable. And a Product instance (or an instance of a number 5, for that matter) is an example of a private dependency that is immutable — a value object. All shared dependencies are mutable, but for a mutable dependency to be shared, it has to be reused by tests.

为了您的方便，我重复表2.1以及学校之间的差异：

I’m repeating table 2.1 with the differences between the schools for your convenience:

经典学派提倡用测试替身替换大部分共享依赖，而伦敦学派也主张替换私有依赖，只要它们是可变的。

The classical school advocates for replacing mostly shared dependencies with test doubles, while the London school stands for the replacement of private dependencies as well, as long as they are mutable.

customer.Purchase(store, Product.Shampoo, 5)

customer.Purchase(store, Product.Shampoo, 5)

让我重申关于依赖类型的一点。并非所有的进程外依赖都属于共享依赖的范畴。共享依赖项几乎总是位于应用程序进程之外，但反之则不然（见图2.5）。为了共享进程外依赖性，它必须为单元测试提供相互通信的方法。通信是通过修改依赖项的内部状态来完成的。从这个意义上说，不可变的进程外依赖不提供这种方法。这些测试根本无法修改其中的任何内容，因此不会干扰彼此的执行上下文。

And let me reiterate one point about the types of dependencies. Not all out-of-process dependencies fall into the category of shared dependencies. A shared dependency almost always resides outside the application’s process, but the opposite isn’t true (see figure 2.5). In order for an out-of-process dependency to be shared, it has to provide means for unit tests to communicate with each other. The communication is done through modifications of the dependency’s internal state. In that sense, an immutable out-of-process dependency doesn’t provide such a means. The tests simply can’t modify anything in it and thus can’t interfere with each other’s execution context.

例如，如果某处有一个 API 可以返回组织销售的所有产品的目录，只要该 API 不公开更改目录的功能，这就不是共享依赖项。确实，这样的依赖关系是易变的并且位于应用程序的边界之外，但是由于测试不会影响它返回的数据，因此它不会被共享。这并不意味着您必须在测试范围中包含此类依赖项。在大多数情况下，您仍然需要将其替换为测试替身以保持测试速度。但是，如果进程外依赖足够快并且与它的连接稳定，那么您可以在测试中很好地使用它。

For example, if there’s an API somewhere that returns a catalog of all products the organization sells, this isn’t a shared dependency as long as the API doesn’t expose the functionality to change the catalog. It’s true that such a dependency is volatile and sits outside the application’s boundary, but since the tests can’t affect the data it returns, it isn’t shared. This doesn’t mean you have to include such a dependency in the testing scope. In most cases, you still need to replace it with a test double to keep the test fast. But if the out-of-process dependency is quick enough and the connection to it is stable, you can make a good case for using it as is in the tests.

话虽如此，在本书中，我交替使用共享依赖和进程外依赖这两个术语，除非我另有明确说明。在实际项目中，您很少有非进程外的共享依赖项。如果依赖项在进程中，您可以轻松地为每个测试提供一个单独的实例；无需在测试之间共享它。同样，您通常不会遇到未共享的进程外依赖项。大多数此类依赖项是可变的，因此可以通过测试进行修改。

Having that said, in this book, I use the terms shared dependency and out-of-process dependency interchangeably unless I explicitly state otherwise. In real-world projects, you rarely have a shared dependency that isn’t out-of-process. If a dependency is in-process, you can easily supply a separate instance of it to each test; there’s no need to share it between tests. Similarly, you normally don’t encounter an out-of-process dependency that’s not shared. Most such dependencies are mutable and thus can be modified by tests.

有了这个定义的基础，让我们对比一下这两个学校的优点。

With this foundation of definitions, let’s contrast the two schools on their merits.

2.3 对比经典单元测试和伦敦单元测试学派

2.3  Contrasting the classical and London schools of unit testing

• 更好的粒度。测试是细粒度的，一次只检查一个类。

• Better granularity. The tests are fine grained and check only one class at a time.

• 对更大的互连类图进行单元测试更容易。由于所有协作者都被测试替身取代，因此您在编写测试时无需担心他们。

• It’s easier to unit test a larger graph of interconnected classes. Since all collaborators are replaced by test doubles, you don’t need to worry about them at the time of writing the test.

• 如果测试失败，您肯定知道哪个功能失败了。没有班级的合作者，除了被测班级本身之外，不可能有任何嫌疑人。

  当然，仍然可能存在被测系统使用了一个值对象的情况，正是这个值对象的变化导致测试失败。但是这些情况并不常见，因为在测试中消除了所有其他依赖项。

• If a test fails, you know for sure which functionality has failed. Without the class’s collaborators, there could be no suspects other than the class under test itself.

  Of course, there may still be situations where the system under test uses a value object and it’s the change in this value object that makes the test fail. But these cases aren’t that frequent because all other dependencies are eliminated in tests.

关于更好粒度的观点与单元测试中单元构成的讨论有关。伦敦学派将班级视为这样一个单元。来自面向对象编程背景的开发人员通常将类视为位于每个代码库基础上的原子构建块。这自然会导致将类也视为要在测试中验证的原子单元。这种倾向是可以理解的，但具有误导性。

The point about better granularity relates to the discussion about what constitutes a unit in unit testing. The London school considers a class as such a unit. Coming from an object-oriented programming background, developers usually regard classes as the atomic building blocks that lie at the foundation of every code base. This naturally leads to treating classes as the atomic units to be verified in tests, too. This tendency is understandable but misleading.

提示

测试不应该验证代码单元。相反，他们应该验证行为单元：对问题域有意义的东西，理想情况下，业务人员可以认为有用的东西。实现这样一个行为单元所需要的类的数量是无关紧要的。它可以跨越多个类，也可以只跨越一个类，甚至只占用一个很小的方法。 Tests shouldn’t verify units of code. Rather, they should verify units of behavior: something that is meaningful for the problem domain and, ideally, something that a business person can recognize as useful. The number of classes it takes to implement such a unit of behavior is irrelevant. It could span across multiple classes, only one class, or even take up just a tiny method.

因此，以更好的代码粒度为目标是没有帮助的。只要测试检查单个行为单元，它就是一个好的测试。定位低于此的目标实际上会损害您的单元测试，因为很难准确理解这些测试验证的内容。测试应该讲述一个关于您的代码帮助解决的问题的故事，这个故事对于非程序员来说应该是连贯的和有意义的。

And so, aiming at better code granularity isn’t helpful. As long as the test checks a single unit of behavior, it’s a good test. Targeting something less than that can in fact damage your unit tests, as it becomes harder to understand exactly what these tests verify. A test should tell a story about the problem your code helps to solve, and this story should be cohesive and meaningful to a non-programmer.

例如，这是一个有凝聚力的故事的例子：

For instance, this is an example of a cohesive story:

当我叫我的狗时，他会马上来找我。

When I call my dog, he comes right to me.

现在将其与以下内容进行比较：

Now compare it to the following:

当我叫我的狗时，他先是左前腿，然后是右前腿，他的头转动，尾巴开始摇摆......

When I call my dog, he moves his front left leg first, then the front right leg, his head turns, the tail start wagging...

第二个故事意义不大。所有这些运动的目的是什么？狗来找我了吗？还是他在逃？你不知道。当您针对单个类（狗的腿、头和尾巴）而不是实际行为（狗来到他的主人身边）时，您的测试就是这样开始的。我将在第 5 章详细讨论可观察行为这个主题以及如何将其与内部实现细节区分开来。

The second story makes much less sense. What’s the purpose of all those movements? Is the dog coming to me? Or is he running away? You can’t tell. This is what your tests start to look like when you target individual classes (the dog’s legs, head, and tail) instead of the actual behavior (the dog coming to his master). I talk more about this topic of observable behavior and how to differentiate it from internal implementation details in chapter 5.

使用模拟代替真正的合作者可以更容易地测试一个类——尤其是当有一个复杂的依赖关系图时，被测类有依赖关系，每个依赖关系都依赖于它自己的依赖关系，等等，几个层深的。使用测试替身，您可以替换类的直接依赖关系，从而分解图形，这可以显着减少您在单元测试中必须做的准备工作。如果您遵循经典学派，您必须重新创建完整的对象图（共享依赖项除外）只是为了设置被测系统，这可能需要大量工作。

The use of mocks in place of real collaborators can make it easier to test a class — especially when there’s a complicated dependency graph, where the class under test has dependencies, each of which relies on dependencies of its own, and so on, several layers deep. With test doubles, you can substitute the class’s immediate dependencies and thus break up the graph, which can significantly reduce the amount of preparation you have to do in a unit test. If you follow the classical school, you have to re-create the full object graph (with the exception of shared dependencies) just for the sake of setting up the system under test, which can be a lot of work.

虽然这一切都是真的，但这种推理集中在错误的问题上。与其寻找方法来测试大型、复杂的互连类图，不如首先关注不要有这样的类图。通常情况下，大型类图是代码设计问题的结果。

Although this is all true, this line of reasoning focuses on the wrong problem. Instead of finding ways to test a large, complicated graph of interconnected classes, you should focus on not having such a graph of classes in the first place. More often than not, a large class graph is a result of a code design problem.

测试指出这个问题实际上是一件好事。正如我们在第 1 章中讨论的那样，对一段代码进行单元测试的能力是一个很好的负面指标——它以相对较高的精度预测较差的代码质量。如果您看到要对一个类进行单元测试，您需要将测试的安排阶段延长到所有合理的限制之外，这是一个麻烦的迹象。使用模拟只是隐藏了这个问题；它没有解决根本原因。我在第 2 部分中讨论了如何解决底层代码设计问题。

And it’s actually a good thing that the tests point out this problem. As we discussed in chapter 1, the ability to unit test a piece of code is a good negative indicator — it predicts poor code quality with a relatively high precision. If you see that to unit test a class, you need to extend the test’s arrange phase beyond all reasonable limits, it’s a certain sign of trouble. The use of mocks only hides this problem; it doesn’t tackle the root cause. I talk about how to fix the underlying code design problem in part 2.

如果您将错误引入具有伦敦式测试的系统，通常只会导致其 SUT 包含该错误的测试失败。然而，使用经典方法，针对故障类的客户端的测试也可能会失败。这会导致连锁反应，其中单个错误可能会导致整个系统的测试失败。结果，找到问题的根源变得更加困难。您可能需要花一些时间调试测试才能弄明白。

If you introduce a bug to a system with London-style tests, it normally causes only tests whose SUT contains the bug to fail. However, with the classical approach, tests that target the clients of the malfunctioning class can also fail. This leads to a ripple effect where a single bug can cause test failures across the whole system. As a result, it becomes harder to find the root of the issue. You might need to spend some time debugging the tests to figure it out.

这是一个合理的担忧，但我不认为这是一个大问题。如果您定期运行测试（理想情况下，在每次源代码更改后），那么您就会知道导致错误的原因——这是您最后编辑的内容，因此找到问题并不难。此外，您不必查看所有失败的测试。修复一个会自动修复所有其他问题。

It’s a valid concern, but I don’t see it as a big problem. If you run your tests regularly (ideally, after each source code change), then you know what caused the bug — it’s what you edited last, so it’s not that difficult to find the issue. Also, you don’t have to look at all the failing tests. Fixing one automatically fixes all the others.

此外，在整个测试套件中级联的故障也有一定的价值。如果一个错误不仅在一个测试中导致错误，而且在很多测试中导致错误，这表明您刚刚破坏的代码片段具有很大的价值——整个系统都依赖于它。这是使用代码时要记住的有用信息。

Furthermore, there’s some value in failures cascading all over the test suite. If a bug leads to a fault in not only one test but a whole lot of them, it shows that the piece of code you have just broken is of great value — the entire system depends on it. That’s useful information to keep in mind when working with the code.

古典学派和伦敦学派之间剩下的两个区别是

Two remaining differences between the classical and London schools are

伦敦风格的单元测试导致由外而内的 TDD，您从更高级别的测试开始，为整个系统设定期望。通过使用模拟，您可以指定系统应与哪些协作者进行通信以实现预期结果。然后，您将逐步完成类图，直到实现每一个类。模拟使这个设计过程成为可能，因为你可以一次专注于一个类。您可以在测试时切断 SUT 的所有协作者，从而将这些协作者的实现推迟到以后的时间。

The London style of unit testing leads to outside-in TDD, where you start from the higher-level tests that set expectations for the whole system. By using mocks, you specify which collaborators the system should communicate with to achieve the expected result. You then work your way through the graph of classes until you implement every one of them. Mocks make this design process possible because you can focus on one class at a time. You can cut off all of the SUT’s collaborators when testing it and thus postpone implementing those collaborators to a later time.

经典学校没有提供完全相同的指导，因为你必须在测试中处理真实的对象。相反，您通常使用由内而外的方法。在这种风格中，您从领域模型开始，然后在其之上放置额外的层，直到最终用户可以使用该软件。

The classical school doesn’t provide quite the same guidance since you have to deal with the real objects in tests. Instead, you normally use the inside-out approach. In this style, you start from the domain model and then put additional layers on top of it until the software becomes usable by the end user.

但这些学校之间最重要的区别是过度规范问题：即将测试与 SUT 的实施细节相结合。伦敦风格倾向于产生比经典风格更频繁地耦合到实现的测试。这是反对无处不在使用模拟和一般伦敦风格的主要反对意见。

But the most crucial distinction between the schools is the issue of over-specification: that is, coupling the tests to the SUT’s implementation details. The London style tends to produce tests that couple to the implementation more often than the classical style. And this is the main objection against the ubiquitous use of mocks and the London style in general.

嘲笑的话题还有很多。从第 4 章开始，我逐渐涵盖了与之相关的所有内容。

There’s much more to the topic of mocking. Starting with chapter 4, I gradually cover everything related to it.

2.5 两校融合测试

2.5  Integration tests in the two schools

• 它验证了一小段代码，

• It verifies a small piece of code,

• 做得很快，

• Does it quickly,

• 并以孤立的方式。

• And in an isolated manner.

• 验证单个行为单元，

• Verifies a single unit of behavior,

• 做得很快，

• Does it quickly,

• 并与其他测试隔离开来。

• And in isolation from other tests.

简而言之，集成测试是一种测试，用于验证您的代码是否可以与共享依赖项、进程外依赖项或组织中其他团队开发的代码集成。还有一个单独的端到端测试概念。端到端测试是集成测试的一个子集。他们也会检查您的代码如何处理进程外依赖项。端到端测试和集成测试之间的区别在于，端到端测试通常包含更多此类依赖项。

In short, an integration test is a test that verifies that your code works in integration with shared dependencies, out-of-process dependencies, or code developed by other teams in the organization. There’s also a separate notion of an end-to-end test. End-to-end tests are a subset of integration tests. They, too, check to see how your code works with out-of-process dependencies. The difference between an end-to-end test and an integration test is that end-to-end tests usually include more of such dependencies.

界限有时是模糊的，但一般来说，集成测试仅适用于一两个进程外依赖项。另一方面，端到端测试适用于所有进程外依赖项，或者适用于其中的绝大多数。因此名称为端到端，这意味着测试从最终用户的角度验证系统，包括该系统集成的所有外部应用程序（见图2.6）。

The line is blurred at times, but in general, an integration test works with only one or two out-of-process dependencies. On the other hand, an end-to-end test works with all out-of-process dependencies, or with the vast majority of them. Hence the name end-to-end, which means the test verifies the system from the end user’s point of view, including all the external applications this system integrates with (see figure 2.6).

人们还使用UI 测试（UI 代表用户界面）、GUI 测试（GUI 是图形用户界面）和功能测试等术语。术语定义不明确，但总的来说，这些术语都是同义词。

People also use such terms as UI tests (UI stands for user interface), GUI tests (GUI is graphical user interface), and functional tests. The terminology is ill-defined, but in general, these terms are all synonyms.

假设您的应用程序使用三个进程外依赖项：数据库、文件系统和支付网关。典型的集成测试将仅包括范围内的数据库和文件系统，并使用测试替身来替换支付网关。那是因为您可以完全控制数据库和文件系统，因此可以轻松地将它们带到测试中所需的状态，而您对支付网关没有相同程度的控制。使用支付网关，您可能需要联系支付处理机构来设置一个特殊的测试账户。您可能还需要不时检查该帐户，以手动清理过去测试执行遗留下来的所有付款费用。

Let’s say your application works with three out-of-process dependencies: a database, the file system, and a payment gateway. A typical integration test would include only the database and file system in scope and use a test double to replace the payment gateway. That’s because you have full control over the database and file system, and thus can easily bring them to the required state in tests, whereas you don’t have the same degree of control over the payment gateway. With the payment gateway, you may need to contact the payment processor organization to set up a special test account. You might also need to check that account from time to time to manually clean up all the payment charges left over from the past test executions.

由于端到端测试在维护方面成本最高，因此最好在构建过程的后期运行它们，在所有单元和集成测试都通过之后。您甚至可能只在构建服务器上运行它们，而不是在各个开发人员的机器上运行。

Since end-to-end tests are the most expensive in terms of maintenance, it’s better to run them late in the build process, after all the unit and integration tests have passed. You may possibly even run them only on the build server, not on individual developers' machines.

请记住，即使使用端到端测试，您也可能无法解决所有进程外依赖项。某些依赖项可能没有测试版本，或者可能无法自动将这些依赖项带到所需状态。

Keep in mind that even with end-to-end tests, you might not be able to tackle all of the out-of-process dependencies. There may be no test version of some dependencies, or it may be impossible to bring those dependencies to the required state automatically.

因此，您可能仍需要使用测试替身，以强化集成测试和端到端测试之间没有明确界限的事实。

So you may still need to use a test double, reinforcing the fact that there isn’t a distinct line between integration and end-to-end tests.

2.6 总结

2.6  Summary

• 在本章中，我细化了单元测试的定义：

  • 单元测试验证单个行为单元，

  • 做得很快，

  • 并与其他测试隔离开来。

• Throughout this chapter, I’ve refined the definition of a unit test:

  • A unit test verifies a single unit of behavior,

  • Does it quickly,

  • And in isolation from other tests.

• 隔离问题是争议最大的。争论导致了两个单元测试学派的形成：经典（底特律）学派和伦敦（模拟）学派。这种意见分歧会影响对什么构成单元的看法以及对被测系统 (SUT) 依赖项的处理。

  • 伦敦学派指出，被测单元应该相互隔离。被测单元是一个代码单元，通常是一个类。它的所有依赖项（不可变依赖项除外）都应在测试中替换为测试替身。

  • 古典学派指出单元测试需要相互隔离，而不是单元。此外，被测单元是行为单元，而不是代码单元。因此，只有共享的依赖关系才应该用测试替身代替。共享依赖项是为测试提供影响彼此执行流程的手段的依赖项。

• The isolation issue is disputed the most. The dispute led to the formation of two schools of unit testing: the classical (Detroit) school, and the London (mockist) school. This difference of opinion affects the view of what constitutes a unit and the treatment of the system under test’s (SUT’s) dependencies.

  • The London school states that the units under test should be isolated from each other. A unit under test is a unit of code, usually a class. All of its dependencies, except immutable dependencies, should be replaced with test doubles in tests.

  • The classical school states that the unit tests need to be isolated from each other, not units. Also, a unit under test is a unit of behavior, not a unit of code. Thus, only shared dependencies should be replaced with test doubles. Shared dependencies are dependencies that provide means for tests to affect each other’s execution flow.

• 伦敦学派提供了更好的粒度、易于测试互连类的大型图以及在测试失败后易于发现哪些功能包含错误的好处。

• The London school provides the benefits of better granularity, the ease of testing large graphs of interconnected classes, and the ease of finding which functionality contains a bug after a test failure.

• 伦敦学校的好处乍一看很吸引人。然而，它们引入了几个问题。首先，对被测类的关注是错误的：测试应该验证行为单元，而不是代码单元。此外，无法对一段代码进行单元测试是代码设计存在问题的强烈迹象。使用测试替身并不能解决这个问题，而只是隐藏它。最后，虽然在测试失败后轻松确定哪些功能包含错误是有帮助的，但这并不是什么大问题，因为您通常知道导致错误的原因 - 这是您最后编辑的内容。

• The benefits of the London school look appealing at first. However, they introduce several issues. First, the focus on classes under test is misplaced: tests should verify units of behavior, not units of code. Furthermore, the inability to unit test a piece of code is a strong sign of a problem with the code design. The use of test doubles doesn’t fix this problem, but rather only hides it. And finally, while the ease of determining which functionality contains a bug after a test failure is helpful, it’s not that big a deal because you often know what caused the bug anyway — it’s what you edited last.

• 伦敦单元测试学院最大的问题是过度规范的问题——将测试耦合到 SUT 的实现细节。

• The biggest issue with the London school of unit testing is the problem of over-specification — coupling tests to the SUT’s implementation details.

• 集成测试是不满足至少一个单元测试标准的测试。端到端测试是集成测试的一个子集；他们从最终用户的角度验证系统。端到端测试直接涉及应用程序使用的所有或几乎所有进程外依赖项。

• An integration test is a test that doesn’t meet at least one of the criteria for a unit test. End-to-end tests are a subset of integration tests; they verify the system from the end user’s point of view. End-to-end tests reach out directly to all or almost all out-of-process dependencies your application works with.

• 对于一本关于经典风格的经典书籍，我推荐 Kent Beck 的测试驱动开发：通过示例。有关伦敦风格的更多信息，请参阅Steve Freeman 和 Nat Pryce 合着的Growing Object-Oriented Software, Guided by Tests 。要进一步阅读有关使用依赖项的信息，我推荐Steven van Deursen 和 Mark Seemann 撰写的《依赖注入：原则、实践和模式》 。

• For a canonical book about the classical style, I recommend Kent Beck’s Test-Driven Development: By Example. For more on the London style, see Growing Object-Oriented Software, Guided by Tests, by Steve Freeman and Nat Pryce. For further reading about working with dependencies, I recommend Dependency Injection: Principles, Practices, Patterns by Steven van Deursen and Mark Seemann.

3.2 探索xUnit测试框架

3.2  Exploring the xUnit testing framework

清单 3.6。所有测试共享的安排和拆卸逻辑

Listing 3.6. Arrangement and teardown logic, shared by all tests

公共类 CalculatorTests：IDisposable
{
    私人只读计算器_sut；

    公共计算器测试（）       ❶ 
    {                              ❶ 
        _sut = 新计算器();   ❶ 
    }                              ❶

    [事实]
    公共无效 Sum_of_two_numbers()
    {
        /* ... */
    }

    公共无效处置（）   ❷ 
    {                       ❷ 
        _sut.CleanUp();     ❷ 
    }                       ❷ 
}

public class CalculatorTests : IDisposable
{
    private readonly Calculator _sut;

    public CalculatorTests()       ❶
    {                              ❶
        _sut = new Calculator();   ❶
    }                              ❶

    [Fact]
    public void Sum_of_two_numbers()
    {
        /* ... */
    }

    public void Dispose()   ❷
    {                       ❷
        _sut.CleanUp();     ❷
    }                       ❷
}

3.3 在测试之间重用测试夹具

3.3  Reusing test fixtures between tests

清单 3.7。将初始化代码提取到测试构造函数中

Listing 3.7. Extracting the initialization code into the test constructor

公开课 CustomerTests
{
    私人只读商店_store；                  ❶
    私人只读客户_sut；

    公共客户测试（）                          ❷ 
    {                                               ❷ 
        _store = new 商店();                       ❷ 
        _store.AddInventory(Product.Shampoo, 10);   ❷ 
        _sut = 新客户();                      ❷ 
    }                                               ❷

    [事实]
    public void Purchase_succeeds_when_enough_inventory()
    {
        bool success = _sut.Purchase(_store, Product.Shampoo, 5);

        断言。真（成功）；
        Assert.Equal(5, _store.GetInventory(Product.Shampoo));
    }

    [事实]
    public void Purchase_fails_when_not_enough_inventory()
    {
        bool success = _sut.Purchase(_store, Product.Shampoo, 15);

        断言.False(成功);
        Assert.Equal(10, _store.GetInventory(Product.Shampoo));
    }
}

public class CustomerTests
{
    private readonly Store _store;                  ❶
    private readonly Customer _sut;

    public CustomerTests()                          ❷
    {                                               ❷
        _store = new Store();                       ❷
        _store.AddInventory(Product.Shampoo, 10);   ❷
        _sut = new Customer();                      ❷
    }                                               ❷

    [Fact]
    public void Purchase_succeeds_when_enough_inventory()
    {
        bool success = _sut.Purchase(_store, Product.Shampoo, 5);

        Assert.True(success);
        Assert.Equal(5, _store.GetInventory(Product.Shampoo));
    }

    [Fact]
    public void Purchase_fails_when_not_enough_inventory()
    {
        bool success = _sut.Purchase(_store, Product.Shampoo, 15);

        Assert.False(success);
        Assert.Equal(10, _store.GetInventory(Product.Shampoo));
    }
}

• 它在测试之间引入了高耦合。

• It introduces high coupling between tests.

• 它降低了测试的可读性。

• It diminishes test readability.

在新版本中，如清单3.7所示，所有测试都相互耦合：修改一个测试的排列逻辑将影响该类中的所有测试。例如，更改此行

In the new version, shown in listing 3.7, all tests are coupled to each other: a modification of one test’s arrangement logic will affect all tests in the class. For example, changing this line

_store.AddInventory(Product.Shampoo, 10);

_store.AddInventory(Product.Shampoo, 10);

对此

to this

_store.AddInventory(Product.Shampoo, 15 );

_store.AddInventory(Product.Shampoo, 15);

会使测试对商店初始状态的假设无效，因此会导致不必要的测试失败。

would invalidate the assumption the tests make about the store’s initial state and therefore would lead to unnecessary test failures.

这违反了一条重要的准则：对一个测试的修改不应影响其他测试。该指南类似于我们在第 2 章中讨论的内容——测试应该彼此隔离运行。但这不一样。在这里，我们说的是独立修改测试，而不是独立执行。两者都是精心设计的测试的重要属性。

That’s a violation of an important guideline: a modification of one test should not affect other tests. This guideline is similar to what we discussed in chapter 2 — that tests should run in isolation from each other. It’s not the same, though. Here, we are talking about independent modification of tests, not independent execution. Both are important attributes of a well-designed test.

要遵循此准则，您需要避免在测试类中引入共享状态。这两个私有字段是这种状态的示例：

To follow this guideline, you need to avoid introducing shared state in test classes. These two private fields are examples of such state:

私人只读商店_store；
私人只读客户_sut；

private readonly Store _store;
private readonly Customer _sut;

将安排代码提取到构造函数中的另一个缺点是降低了测试可读性。您不再仅通过查看测试本身就可以看到全貌。您必须检查类中的不同位置以了解测试方法的作用。

The other drawback to extracting the arrangement code into the constructor is diminished test readability. You no longer see the full picture just by looking at the test itself. You have to examine different places in the class to understand what the test method does.

即使没有太多的排列逻辑——比如说，只有 fixture 的实例化——你仍然最好将它直接移动到测试方法。否则，您会想知道它是否真的只是实例化，还是那里也配置了其他东西。一个独立的测试不会给你留下这样的不确定性。

Even if there’s not much arrangement logic — say, only instantiation of the fixtures — you are still better off moving it directly to the test method. Otherwise, you’ll wonder if it’s really just instantiation or something else is being configured there, too. A self-contained test doesn’t leave you with such uncertainties.

在重用测试装置时，使用构造函数并不是最好的方法。第二种方法——有益的方法——是在测试类中引入私有工厂方法，如以下清单所示。

The use of the constructor is not the best approach when it comes to reusing test fixtures. The second way — the beneficial one — is to introduce private factory methods in the test class, as shown in the following listing.

公开课 CustomerTests
{
    [事实]
    public void Purchase_succeeds_when_enough_inventory()
    {
        Store store = CreateStoreWithInventory(Product.Shampoo, 10);
        客户 sut = CreateCustomer();

        bool success = sut.Purchase(store, Product.Shampoo, 5);

        断言。真（成功）；
        Assert.Equal(5, store.GetInventory(Product.Shampoo));
    }

    [事实]
    public void Purchase_fails_when_not_enough_inventory()
    {
        Store store = CreateStoreWithInventory(Product.Shampoo, 10);
        客户 sut = CreateCustomer();

        bool success = sut.Purchase(store, Product.Shampoo, 15);

        断言.False(成功);
        Assert.Equal(10, store.GetInventory(Product.Shampoo));
    }

    私人商店 CreateStoreWithInventory(
        Product 产品, int 数量)
    {
        商店商店=新商店（）；
        store.AddInventory（产品，数量）；
        退货商店；
    }

    私有静态客户 CreateCustomer()
    {
        返回新客户（）；
    }
}

public class CustomerTests
{
    [Fact]
    public void Purchase_succeeds_when_enough_inventory()
    {
        Store store = CreateStoreWithInventory(Product.Shampoo, 10);
        Customer sut = CreateCustomer();

        bool success = sut.Purchase(store, Product.Shampoo, 5);

        Assert.True(success);
        Assert.Equal(5, store.GetInventory(Product.Shampoo));
    }

    [Fact]
    public void Purchase_fails_when_not_enough_inventory()
    {
        Store store = CreateStoreWithInventory(Product.Shampoo, 10);
        Customer sut = CreateCustomer();

        bool success = sut.Purchase(store, Product.Shampoo, 15);

        Assert.False(success);
        Assert.Equal(10, store.GetInventory(Product.Shampoo));
    }

    private Store CreateStoreWithInventory(
        Product product, int quantity)
    {
        Store store = new Store();
        store.AddInventory(product, quantity);
        return store;
    }

    private static Customer CreateCustomer()
    {
        return new Customer();
    }
}

通过将公共初始化代码提取到私有工厂方法中，您还可以缩短测试代码，但同时保留测试中发生的事情的完整上下文。此外，只要您使私有方法足够通用，它们就不会相互耦合测试。也就是说，允许测试指定他们希望如何创建固定装置。

By extracting the common initialization code into private factory methods, you can also shorten the test code, but at the same time keep the full context of what’s going on in the tests. Moreover, the private methods don’t couple tests to each other as long as you make them generic enough. That is, allow the tests specify how they want the fixtures be created.

看看这一行，例如：

Look at this line, for example:

Store store = CreateStoreWithInventory(Product.Shampoo, 10);

Store store = CreateStoreWithInventory(Product.Shampoo, 10);

该测试明确指出它希望工厂方法向商店添加 10 单位洗发水。这是高度可读和可重用的。它具有可读性，因为您无需检查工厂方法的内部结构即可了解所创建商店的属性。它是可重用的，因为您也可以在其他测试中使用此方法。

The test explicitly states that it wants the factory method to add 10 units of shampoo to the store. This is both highly readable and reusable. It’s readable because you don’t need to examine the internals of the factory method to understand the attributes of the created store. It’s reusable because you can utilize this method in other tests, too.

请注意，在这个特定的示例中，不需要引入工厂方法，因为排列逻辑非常简单。仅将其视为演示。

Note that in this particular example, there’s no need to introduce factory methods, as the arrangement logic is quite simple. View it merely as a demonstration.

重用测试夹具这一规则有一个例外。如果所有或几乎所有测试都使用了夹具，则可以在构造函数中实例化夹具。使用数据库的集成测试通常就是这种情况。所有这些测试都需要一个数据库连接，您可以初始化一次，然后在任何地方重复使用。但即便如此，引入基类并在该类的构造函数中初始化数据库连接更有意义，而不是在单独的测试类中。

There’s one exception to this rule of reusing test fixtures. You can instantiate a fixture in the constructor if it’s used by all or almost all tests. This is often the case for integration tests that work with a database. All such tests require a database connection, which you can initialize once and then reuse everywhere. But even then, it would make more sense to introduce a base class and initialize the database connection in that class’s constructor, not in individual test classes.

公共类客户测试：集成测试
{
    [事实]
    public void Purchase_succeeds_when_enough_inventory()
    {
        /* 在这里使用_database */
    }
}

公共抽象类集成测试：IDisposable
{
    受保护的只读数据库_database；

    受保护的 IntegrationTests()
    {
        _database = 新数据库();
    }

    公共无效处置（）
    {
        _database.Dispose();
    }
}

public class CustomerTests : IntegrationTests
{
    [Fact]
    public void Purchase_succeeds_when_enough_inventory()
    {
        /* use _database here */
    }
}

public abstract class IntegrationTests : IDisposable
{
    protected readonly Database _database;

    protected IntegrationTests()
    {
        _database = new Database();
    }

    public void Dispose()
    {
        _database.Dispose();
    }
}

注意如何CustomerTests保持无构造函数。_database它通过从基类继承来访问实例IntegrationTests。

Notice how CustomerTests remains constructor-less. It gets access to the _database instance by inheriting from the IntegrationTests base class.

3.4 命名单元测试

3.4  Naming a unit test

• MethodUnderTest是您正在测试的方法的名称。

• MethodUnderTest is the name of the method you are testing.

• Scenario是测试方法的条件。

• Scenario is the condition under which you test the method.

• ExpectedResult是您期望被测方法在当前场景中执行的操作。

• ExpectedResult is what you expect the method under test to do in the current scenario.

公共课计算器测试
{
    [事实]
    公共无效 Sum_of_two_numbers()
    {
        双先= 10;
        双秒 = 20；
        var sut = 新计算器();

        double result = sut.Sum(first, second);

        Assert.Equal(30, 结果);
    }
}

public class CalculatorTests
{
    [Fact]
    public void Sum_of_two_numbers()
    {
        double first = 10;
        double second = 20;
        var sut = new Calculator();

        double result = sut.Sum(first, second);

        Assert.Equal(30, result);
    }
}

公共无效 Sum_TwoNumbers_ReturnsSum()

public void Sum_TwoNumbers_ReturnsSum()

公共无效 Sum_of_two_numbers()
公共无效 Sum_TwoNumbers_ReturnsSum()

public void Sum_of_two_numbers()
public void Sum_TwoNumbers_ReturnsSum()

遵循以下准则来编写富有表现力、易于阅读的测试名称：

Adhere to the following guidelines to write expressive, easily readable test names:

请注意，我在命名测试类时没有使用下划线，CalculatorTests. 类的名字通常不会那么长，所以没有下划线也能读起来很好。

Notice that I didn’t use underscores when naming the test class, CalculatorTests. Classes' names normally are not as long, so they read fine without underscores.

另请注意，虽然我在命名测试类时使用了该模式[ClassName]Tests，但这并不意味着测试仅限于验证ClassName. 请记住，单元测试中的单元是行为单元，而不是类。这个单元可以跨越一个或几个班级；实际大小无关紧要。不过，你必须从某个地方开始。将类视为[ClassName]Tests：一个入口点，一个 API，您可以使用它来验证一个行为单元。

Also notice that although I use the pattern [ClassName]Tests when naming test classes, it doesn’t mean the tests are limited to verifying only that ClassName. Remember, the unit in unit testing is a unit of behavior, not a class. This unit can span across one or several classes; the actual size is irrelevant. Still, you have to start somewhere. View the class in [ClassName]Tests as just that: an entry point, an API, using which you can verify a unit of behavior.

让我们以一个测试为例，并尝试使用我刚才概述的指南逐步改进它的名称。在下面的清单中，您可以看到一个测试，用于验证具有过去日期的交付是否无效。测试的名称是使用不利于测试可读性的严格命名策略编写的。

Let’s take a test as an example and try to gradually improve its name using the guidelines I just outlined. In the following listing, you can see a test verifying that a delivery with a past date is invalid. The test’s name is written using the rigid naming policy that doesn’t help with the test readability.

[事实]
public void IsDeliveryValid_InvalidDate_ReturnsFalse()
{
    DeliveryService sut = new DeliveryService();
    日期时间 pastDate = DateTime.Now.AddDays(-1);
    交货交货=新交货
    {
        日期 = 过去日期
    };

    bool isValid = sut.IsDeliveryValid(交付);

    断言.False(isValid);
}

[Fact]
public void IsDeliveryValid_InvalidDate_ReturnsFalse()
{
    DeliveryService sut = new DeliveryService();
    DateTime pastDate = DateTime.Now.AddDays(-1);
    Delivery delivery = new Delivery
    {
        Date = pastDate
    };

    bool isValid = sut.IsDeliveryValid(delivery);

    Assert.False(isValid);
}

此测试检查是否DeliveryService正确地将日期不正确的交付标识为无效。您将如何用简单的英语重写测试名称？以下将是一个很好的第一次尝试：

This test checks that DeliveryService properly identifies a delivery with an incorrect date as invalid. How would you rewrite the test’s name in plain English? The following would be a good first try:

public void Delivery_with_invalid_date_should_be_considered_invalid()

public void Delivery_with_invalid_date_should_be_considered_invalid()

在新版本中注意两件事：

Notice two things in the new version:

第二点是用简单的英语重写测试名称的自然结果，因此很容易被忽略。然而，这个结果很重要，可以提升为自己的指导方针。

The second point is a natural consequence of rewriting the test’s name in plain English and thus can be easily overlooked. However, this consequence is important and can be elevated into a guideline of its own.

	警告
	不要在测试名称中包含 SUT 方法的名称。 Don’t include the name of the SUT’s method in the test’s name.

但是让我们回到这个例子。新版本的测试名称是一个好的开始，但还可以进一步改进。交货日期无效究竟意味着什么？从清单3.10中的测试中，我们可以看到无效日期是过去的任何日期。这是有道理的——你应该只被允许选择未来的交货日期。

But let’s get back to the example. The new version of the test’s name is a good start, but it can be improved further. What does it mean for a delivery date to be invalid, exactly? From the test in listing 3.10, we can see that an invalid date is any date in the past. This makes sense — you should only be allowed to choose a delivery date in the future.

因此，让我们具体一点，并在测试名称中反映这些知识：

So let’s be specific and reflect this knowledge in the test’s name:

public void Delivery_with_past_date_should_be_considered_invalid()

public void Delivery_with_past_date_should_be_considered_invalid()

这更好但仍然不理想。太冗长了。considered我们可以在不失去任何意义的情况下去掉这个词：

This is better but still not ideal. It’s too verbose. We can get rid of the word considered without any loss of meaning:

public void Delivery_with_past_date_should_be_invalid()

public void Delivery_with_past_date_should_be_invalid()

措辞should be是另一种常见的反模式。在本章的前面，我提到过测试是关于行为单元的单个原子事实。陈述事实时，没有愿望或愿望的余地。相应地命名测试——替换应该是：

The wording should be is another common anti-pattern. Earlier in this chapter I mentioned that a test is a single, atomic fact about a unit of behavior. There’s no place for a wish or a desire when stating a fact. Name the test accordingly — replace should be with is:

public void Delivery_with_past_date_is_invalid()

public void Delivery_with_past_date_is_invalid()

最后，无需回避基本的英语语法。文章帮助测试完美阅读。将文章a添加到测试的名称中：

And finally, there’s no need to avoid basic English grammar. Articles help the test read flawlessly. Add the article a to the test’s name:

public void Delivery_with_a_past_date_is_invalid()

public void Delivery_with_a_past_date_is_invalid()

给你。这个最终版本是对一个事实的直截了当的陈述，它本身描述了被测应用程序行为的一个方面：在这种特殊情况下，确定是否可以完成交付的方面。

There you go. This final version is a straight-to-the-point statement of a fact, which itself describes one of the aspects of the application behavior under test: in this particular case, the aspect of determining whether a delivery can be done.

3.5 重构参数化测试

3.5  Refactoring to parameterized tests

public void Delivery_for_today_is_invalid()
public void Delivery_for_tomorrow_is_invalid()
public void The_soonest_delivery_date_is_two_days_from_now()

public void Delivery_for_today_is_invalid()
public void Delivery_for_tomorrow_is_invalid()
public void The_soonest_delivery_date_is_two_days_from_now()

清单 3.11。包含多个事实的测试

Listing 3.11. A test that encompasses several facts

公共类 DeliveryServiceTests
{
    [内联数据（-1，假）]   ❶ 
    [InlineData(0, false)]    ❶ 
    [InlineData(1, false)]    ❶ 
    [内联数据(2, 真)]     ❶
    [理论]
    公共无效 Can_detect_an_invalid_delivery_date(
        int daysFromNow,   ❷
        布尔预期）     ❷
    {
        DeliveryService sut = new DeliveryService();
        日期时间 deliveryDate = DateTime.Now
            .AddDays(daysFromNow);   ❸
        交货交货=新交货
        {
            日期 = 交货日期
        };

        bool isValid = sut.IsDeliveryValid(交付);

        Assert.Equal(expected, isValid);   ❸
    }
}

public class DeliveryServiceTests
{
    [InlineData(-1, false)]   ❶
    [InlineData(0, false)]    ❶
    [InlineData(1, false)]    ❶
    [InlineData(2, true)]     ❶
    [Theory]
    public void Can_detect_an_invalid_delivery_date(
        int daysFromNow,   ❷
        bool expected)     ❷
    {
        DeliveryService sut = new DeliveryService();
        DateTime deliveryDate = DateTime.Now
            .AddDays(daysFromNow);   ❸
        Delivery delivery = new Delivery
        {
            Date = deliveryDate
        };

        bool isValid = sut.IsDeliveryValid(delivery);

        Assert.Equal(expected, isValid);   ❸
    }
}

清单 3.12。验证正面和负面场景的两个测试

Listing 3.12. Two tests verifying the positive and negative scenarios

公共类 DeliveryServiceTests
{
    [内联数据(-1)]
    [内联数据(0)]
    [内联数据(1)]
    [理论]
    public void Detects_an_invalid_delivery_date(int daysFromNow)
    {
        /* ... */
    }

    [事实]
    public void The_soonest_delivery_date_is_two_days_from_now()
    {
        /* ... */
    }
}

public class DeliveryServiceTests
{
    [InlineData(-1)]
    [InlineData(0)]
    [InlineData(1)]
    [Theory]
    public void Detects_an_invalid_delivery_date(int daysFromNow)
    {
        /* ... */
    }

    [Fact]
    public void The_soonest_delivery_date_is_two_days_from_now()
    {
        /* ... */
    }
}

在使用参数化测试（至少在 .NET 中）时需要注意一些注意事项。请注意，在清单3.11中，我使用daysFromNow参数作为测试方法的输入。您可能会问，为什么不是实际的日期和时间？不幸的是，以下代码将不起作用：

There are some caveats in using parameterized tests (at least, in .NET) that you need to be aware of. Notice that in listing 3.11, I used the daysFromNow parameter as an input to the test method. Why not the actual date and time, you might ask? Unfortunately, the following code won’t work:

[InlineData( DateTime.Now.AddDays(-1) , false)]
[InlineData( DateTime.Now , false)]
[InlineData( DateTime.Now.AddDays(1) , false)]
[InlineData( DateTime.Now.AddDays(2) , true)]
[理论]
公共无效 Can_detect_an_invalid_delivery_date(
    日期时间交货日期，
    预计布尔值）
{
    DeliveryService sut = new DeliveryService();
    交货交货=新交货
    {
        日期 =交货日期
    };

    bool isValid = sut.IsDeliveryValid(交付);

    Assert.Equal(expected, isValid);
}

[InlineData(DateTime.Now.AddDays(-1), false)]
[InlineData(DateTime.Now, false)]
[InlineData(DateTime.Now.AddDays(1), false)]
[InlineData(DateTime.Now.AddDays(2), true)]
[Theory]
public void Can_detect_an_invalid_delivery_date(
    DateTime deliveryDate,
    bool expected)
{
    DeliveryService sut = new DeliveryService();
    Delivery delivery = new Delivery
    {
        Date = deliveryDate
    };

    bool isValid = sut.IsDeliveryValid(delivery);

    Assert.Equal(expected, isValid);
}

在 C# 中，所有属性的内容都在编译时求值。您必须仅使用编译器可以理解的那些值，如下所示：

In C#, the content of all attributes is evaluated at compile time. You have to use only those values that the compiler can understand, which are as follows:

对 的调用DateTime.Now依赖于 .NET 运行时，因此是不允许的。

The call to DateTime.Now relies on the .NET runtime and thus is not allowed.

有一种方法可以克服这个问题。xUnit 还有另一个功能，您可以使用它来生成自定义数据以输入测试方法：[MemberData]. 下一个清单显示了我们如何使用此功能重写之前的测试。

There is a way to overcome this problem. xUnit has another feature that you can use to generate custom data to feed into the test method: [MemberData]. The next listing shows how we can rewrite the previous test using this feature.

[理论]
[成员数据（名称（数据））]
公共无效 Can_detect_an_invalid_delivery_date(
    日期时间交货日期，
    预计布尔值）
{
    /* ... */
}

公共静态列表<对象[]> 数据()
{
    返回新列表<object[]>
    {
        新对象[] { DateTime.Now.AddDays(-1), false },
        新对象[] { DateTime.Now, false },
        新对象[] { DateTime.Now.AddDays(1), false },
        新对象 [] { DateTime.Now.AddDays(2), true }
    };
}

[Theory]
[MemberData(nameof(Data))]
public void Can_detect_an_invalid_delivery_date(
    DateTime deliveryDate,
    bool expected)
{
    /* ... */
}

public static List<object[]> Data()
{
    return new List<object[]>
    {
        new object[] { DateTime.Now.AddDays(-1), false },
        new object[] { DateTime.Now, false },
        new object[] { DateTime.Now.AddDays(1), false },
        new object[] { DateTime.Now.AddDays(2), true }
    };
}

MemberData接受生成输入数据集合的静态方法的名称（编译器翻译nameof(Data)成"Data"文字）。集合的每个元素本身就是一个映射到两个输入参数的集合：deliveryDate和expected。有了这个特性，你就可以克服编译器的限制，在参数化测试中使用任意类型的参数。

MemberData accepts the name of a static method that generates a collection of input data (the compiler translates nameof(Data) into a "Data" literal). Each element of the collection is itself a collection that is mapped into the two input parameters: deliveryDate and expected. With this feature, you can overcome the compiler’s restrictions and use parameters of any type in the parameterized tests.

3.6 使用断言库进一步提高测试可读性

3.6  Using an assertion library to further improve test readability

[事实]
公共无效 Sum_of_two_numbers()
{
    var sut = 新计算器();

    双结果 = sut.Sum(10, 20);

    Assert.Equal(30, 结果);
}

[Fact]
public void Sum_of_two_numbers()
{
    var sut = new Calculator();

    double result = sut.Sum(10, 20);

    Assert.Equal(30, result);
}

[事实]
公共无效 Sum_of_two_numbers()
{
    var sut = 新计算器();

    双结果 = sut.Sum(10, 20);

    结果.Should().Be(30);
}

[Fact]
public void Sum_of_two_numbers()
{
    var sut = new Calculator();

    double result = sut.Sum(10, 20);

    result.Should().Be(30);
}

[主题] [行动] [对象]。

[Subject] [action] [object].

鲍勃打开门。

Bob opened the door.

3.7 总结

3.7  Summary

• 所有单元测试都应遵循 AAA 模式：安排、行动、断言。如果测试有多个arrange、act或assert部分，则表明该测试同时验证了多个行为单元。如果这个测试是一个单元测试，把它分成几个测试——每个动作一个。

• All unit tests should follow the AAA pattern: arrange, act, assert. If a test has multiple arrange, act, or assert sections, that’s a sign that the test verifies multiple units of behavior at once. If this test is meant to be a unit test, split it into several tests — one per each action.

• act部分中多于一行表示 SUT 的 API 有问题。它要求客户记住始终一起执行这些操作，这可能会导致不一致。这种不一致称为不变违规。保护您的代码免受潜在的不变违规的行为称为封装。

• More than one line in the act section is a sign of a problem with the SUT’s API. It requires the client to remember to always perform these actions together, which can potentially lead to inconsistencies. Such inconsistencies are called invariant violations. The act of protecting your code against potential invariant violations is called encapsulation.

• 通过命名来区分测试中的 SUT sut。通过在它们之前放置Arrange、Act和Assert注释或在这些部分之间引入空行来区分三个测试部分。

• Distinguish the SUT in tests by naming it sut. Differentiate the three test sections either by putting Arrange, Act, and Assert comments before them or by introducing empty lines between these sections.

• 通过引入工厂方法来重用测试夹具初始化代码，而不是将此初始化代码放入构造函数中。这种重用有助于保持测试之间的高度解耦，并提供更好的可读性。

• Reuse test fixture initialization code by introducing factory methods, not by putting this initialization code to the constructor. Such reuse helps maintain a high degree of decoupling between tests and also provides better readability.

• 不要使用严格的测试命名策略。为每个测试命名，就好像您正在向熟悉问题域的非程序员描述其中的场景一样。测试名称中的单词用下划线分隔，测试名称中不要包含被测方法的名称。

• Don’t use a rigid test naming policy. Name each test as if you were describing the scenario in it to a non-programmer who is familiar with the problem domain. Separate words in the test name by underscores, and don’t include the name of the method under test in the test name.

• 参数化测试有助于减少类似测试所需的代码量。缺点是当您使测试名称更通用时，测试名称的可读性会降低。

• Parameterized tests help reduce the amount of code needed for similar tests. The drawback is that the test names become less readable as you make them more generic.

• 断言库通过重组断言中的词序来帮助您进一步提高测试的可读性，使它们读起来像简单的英语。

• Assertion libraries help you further improve test readability by restructuring the word order in assertions so that they read like plain English.

4.2 前两个属性的内在联系

4.2  The intrinsic connection between the first two attributes

• 最大限度地提高测试精度

• Maximizing test accuracy

• 假阳性和假阴性的重要性

• The importance of false positives and false negatives

让我们退后一步，看看有关测试结果的更广泛的情况。在代码正确性和测试结果方面，有四种可能的结果，如图4.3所示。测试可以通过或失败（表的行）。功能本身可以是正确的也可以是错误的（表的列）。

Let’s step back for a second and look at the broader picture with regard to test results. When it comes to code correctness and test results, there are four possible outcomes, as shown in figure 4.3. The test can either pass or fail (the rows of the table). And the functionality itself can be either correct or broken (the table’s columns).

测试通过并且底层功能按预期工作的情况是正确的推断：测试正确地推断出系统的状态（其中没有错误）。这种工作功能和通过测试的组合的另一个术语是真阴性。

The situation when the test passes and the underlying functionality works as intended is a correct inference: the test correctly inferred the state of the system (there are no bugs in it). Another term for this combination of working functionality and a passing test is true negative.

同样，当功能被破坏并且测试失败时，它也是一个正确的推理。那是因为您希望在功能无法正常工作时看到测试失败。这就是单元测试的重点。这种情况对应的术语是true positive。

Similarly, when the functionality is broken and the test fails, it’s also a correct inference. That’s because you expect to see the test fail when the functionality is not working properly. That’s the whole point of unit testing. The corresponding term for this situation is true positive.

但是当测试没有发现错误时，那就是一个问题。这是右上象限，假阴性。这就是一个好的测试的第一个属性——防止回归——可以帮助你避免的。具有良好的回归保护的测试可以帮助您最大程度地减少假阴性的数量 - II 类错误。

But when the test doesn’t catch an error, that’s a problem. This is the upper-right quadrant, a false negative. And this is what the first attribute of a good test — protection against regressions — helps you avoid. Tests with a good protection against regressions help you to minimize the number of false negatives — type II errors.

另一方面，当功能正确但测试仍然显示失败时，存在对称情况。这是误报，误报。这就是第二个属性——抗重构——可以帮助你的。

On the other hand, there’s a symmetric situation when the functionality is correct but the test still shows a failure. This is a false positive, a false alarm. And this is what the second attribute — resistance to refactoring — helps you with.

所有这些术语（误报、I 类错误等）都源于统计学，但也可以应用于分析测试套件。了解它们的最佳方法是考虑进行流感测试。当接受测试的人患有流感时，流感测试呈阳性。阳性这个词有点令人困惑，因为得了流感没有什么阳性的。但测试并没有评估整体情况。在测试的上下文中，肯定意味着某些条件集现在为真。这些是测试的创建者设置的反应条件。在这个特定的例子中，它是流感的存在。相反，没有流感会使流感检测呈阴性。

All these terms (false positive, type I error and so on) have roots in statistics, but can also be applied to analyzing a test suite. The best way to wrap your head around them is to think of a flu test. A flu test is positive when the person taking the test has the flu. The term positive is a bit confusing because there’s nothing positive about having the flu. But the test doesn’t evaluate the situation as a whole. In the context of testing, positive means that some set of conditions is now true. Those are the conditions the creators of the test have set it to react to. In this particular example, it’s the presence of the flu. Conversely, the lack of flu renders the flu test negative.

现在，当您评估流感测试的准确性时，您会提出诸如假阳性或假阴性之类的术语。假阳性和假阴性的概率告诉您流感测试的好坏：概率越低，测试越准确。

Now, when you evaluate how accurate the flu test is, you bring up terms such as false positive or false negative. The probability of false positives and false negatives tells you how good the flu test is: the lower that probability, the more accurate the test.

这种准确性是良好单元测试的前两个支柱。防止回归和抵制重构旨在最大限度地提高测试套件的准确性。准确性指标本身由两个部分组成：

This accuracy is what the first two pillars of a good unit test are all about. Protection against regressions and resistance to refactoring aim at maximizing the accuracy of the test suite. The accuracy metric itself consists of two components:

考虑误报和漏报的另一种方法是根据信噪比。从图4.4的公式可以看出，有两种方法可以提高测试精度。第一个是增加分子signal：也就是说，使测试更好地发现回归。第二个是减少分母，噪声：使测试更好地避免误报。

Another way to think of false positives and false negatives is in terms of signal-to-noise ratio. As you can see from the formula in figure 4.4, there are two ways to improve test accuracy. The first is to increase the numerator, signal: that is, make the test better at finding regressions. The second is to reduce the denominator, noise: make the test better at not raising false alarms.

两者都至关重要。无法发现任何错误的测试是没有用的，即使它不会引发误报。同样，即使它能够找到代码中的所有错误，当它产生大量噪音时，测试的准确性也会变为零。这些发现完全淹没在无关信息的海洋中。

Both are critically important. There’s no use for a test that isn’t capable of finding any bugs, even if it doesn’t raise false alarms. Similarly, the test’s accuracy goes to zero when it generates a lot of noise, even if it’s capable of finding all the bugs in code. These findings are simply lost in the sea of irrelevant information.

短期内，假阳性不如假阴性严重。在项目开始时，收到一个错误的警告并不是什么大不了的事，而不是根本没有收到警告并冒着错误进入生产的风险。但随着项目的增长，误报开始对测试套件产生越来越大的影响（图4.5）。

In the short term, false positives are not as bad as false negatives. In the beginning of a project, receiving a wrong warning is not that big a deal as opposed to not being warned at all and running the risk of a bug slipping into production. But as the project grows, false positives start to have an increasingly large effect on the test suite (figure 4.5).

为什么误报最初没有那么重要？因为重构的重要性也不是立竿见影的；它随着时间的推移逐渐增加。您不需要在项目开始时进行很多代码清理。新编写的代码通常闪闪发光且完美无缺。它还对您记忆犹新，因此即使测试出现误报，您也可以轻松重构它。

Why are false positives not as important initially? Because the importance of refactoring is also not immediate; it increases gradually over time. You don’t need to conduct many code clean-ups in the beginning of the project. Newly written code is often shiny and flawless. It’s also still fresh in your memory, so you can easily refactor it even if tests raise false alarms.

但随着时间的推移，代码库会恶化。它变得越来越复杂和混乱。因此，您必须开始定期进行重构以减轻这种趋势。否则，引入新功能的成本最终会变得令人望而却步。

But as time goes on, the code base deteriorates. It becomes increasingly complex and disorganized. Thus you have to start conducting regular refactorings in order to mitigate this tendency. Otherwise, the cost of introducing new features eventually becomes prohibitive.

随着重构需求的增加，测试中抵制重构的重要性也随之增加。正如我之前解释的那样，当测试不断地叫喊“狼来了”并且你不断收到关于不存在的错误的警告时，你就无法重构。您很快就会对此类测试失去信任，不再将它们视为可靠的反馈来源。

As the need for refactoring increases, the importance of resistance to refactoring in tests increases with it. As I explained earlier, you can’t refactor when the tests keep crying "wolf" and you keep getting warnings about bugs that don’t exist. You quickly lose trust in such tests and stop viewing them as a reliable source of feedback.

尽管保护您的代码免受误报非常重要，尤其是在项目的后期阶段，但很少有开发人员以这种方式看待误报。大多数人倾向于只关注改进良好单元测试的第一个属性——防止回归，这不足以构建有助于维持项目增长的有价值、高度准确的测试套件。

Despite the importance of protecting your code against false positives, especially in the later project stages, few developers perceive false positives this way. Most people tend to focus solely on improving the first attribute of a good unit test — protection against regressions, which is not enough to build a valuable, highly accurate test suite that helps sustain project growth.

当然，原因是进入后期阶段的项目要少得多，主要是因为它们很小，而且在项目变得太大之前就完成了开发。因此，开发人员面临的问题是未被注意到的错误，而不是大量涌入项目并阻碍所有重构工作的错误警报。因此，人们会相应地进行优化。然而，如果您从事中型到大型项目，则必须对漏报（未注意到的错误）和误报（误报）给予同等的关注。

The reason, of course, is that far fewer projects get to those later stages, mostly because they are small and the development finishes before the project becomes too big. Thus developers face the problem of unnoticed bugs more often than false alarms that swarm the project and hinder all refactoring undertakings. And so, people optimize accordingly. Nevertheless, if you work on a medium to large project, you have to pay equal attention to both false negatives (unnoticed bugs) and false positives (false alarms).

4.3 第三和第四支柱：快速反馈和可维护性

4.3  The third and fourth pillars: Fast feedback and maintainability

• 快速反馈

• Fast feedback

• 可维护性

• Maintainability

• 理解测试的难易程度 ——这个部分与测试的大小有关。测试中的代码行越少，测试的可读性就越高。在需要时更改小测试也更容易。当然，这是假设您不试图人为地压缩测试代码以减少行数。测试代码的质量与生产代码一样重要。编写测试时不要偷工减料；将测试代码视为一等公民。

• How hard it is to understand the test — This component is related to the size of the test. The fewer lines of code in the test, the more readable the test is. It’s also easier to change a small test when needed. Of course, that’s assuming you don’t try to compress the test code artificially just to reduce the line count. The quality of the test code matters as much as the production code. Don’t cut corners when writing tests; treat the test code as a first-class citizen.

• 运行测试有多难 ——如果测试使用进程外依赖项，您必须花时间保持这些依赖项可操作：重新启动数据库服务器，解决网络连接问题，等等。

• How hard it is to run the test — If the test works with out-of-process dependencies, you have to spend time keeping those dependencies operational: reboot the database server, resolve network connectivity issues, and so on.

4.4 寻找理想的测试

4.4  In search of an ideal test

• 防止回归

• Protection against regressions

• 抵制重构

• Resistance to refactoring

• 快速反馈

• Fast feedback

• 可维护性

• Maintainability

价值估计 = [0..1] * [0..1] * [0..1] * [0..1]

Value estimate = [0..1] * [0..1] * [0..1] * [0..1]

理想的测试是在所有四个属性中得分最高的测试。0如果您为1每个属性取最小值和最大值，则理想的测试必须1包含所有属性。

An ideal test is a test that scores the maximum in all four attributes. If you take the minimum and maximum values as 0 and 1 for each of the attributes, an ideal test must get 1 in all of them.

不幸的是，不可能创建这样一个理想的测试。原因是前三个属性—— 防止回归、抵抗重构和快速反馈 ——是相互排斥的。不可能将它们全部最大化：您必须牺牲三个中的一个才能最大化剩余的两个。

Unfortunately, it’s impossible to create such an ideal test. The reason is that the first three attributes — protection against regressions, resistance to refactoring, and fast feedback — are mutually exclusive. It’s impossible to maximize them all: you have to sacrifice one of the three in order to max out the remaining two.

而且，由于乘法原理（参见上一节的估值计算），保持平衡更加棘手。你不能为了专注于其他属性而放弃其中一个属性。正如我之前提到的，在四个类别之一中得分为零的测试毫无价值。因此，您必须最大化这些属性，以免它们中的任何一个都减少太多。让我们看一些测试示例，这些测试旨在以牺牲第三个属性为代价来最大化三个属性中的两个，结果，其值接近于零。

Moreover, because of the multiplication principle (see the calculation of the value estimate in the previous section), it’s even trickier to keep the balance. You can’t just forgo one of the attributes in order to focus on the others. As I mentioned previously, a test that scores zero in one of the four categories is worthless. Therefore, you have to maximize these attributes in such a way that none of them is diminished too much. Let’s look at some examples of tests that aim at maximizing two out of three attributes at the expense of the third and, as a result, have a value that’s close to zero.

第一个例子是端到端测试。你可能还记得第 2 章，端到端测试是从最终用户的角度来看系统的。它们通常会遍历系统的所有组件，包括 UI、数据库和外部应用程序。

The first example is end-to-end tests. As you may remember from chapter 2, end-to-end tests look at the system from the end user’s perspective. They normally go through all of the system’s components, including the UI, database, and external applications.

由于端到端测试运行了大量代码，因此它们提供了最好的回归保护。事实上，在所有类型的测试中，端到端测试使用的代码最多——包括您的代码和您没有编写但在项目中使用的代码，例如外部库、框架和第三方应用程序。

Since end-to-end tests exercise a lot of code, they provide the best protection against regressions. In fact, of all types of tests, end-to-end tests exercise the most code — both your code and the code you didn’t write but use in the project, such as external libraries, frameworks, and third-party applications.

端到端测试也不受误报影响，因此对重构有很好的抵抗力。如果重构正确，则不会改变系统的可观察行为，因此不会影响端到端测试。这是此类测试的另一个优势：它们不强加任何特定的实现。端到端测试唯一关注的是从最终用户的角度来看功能的行为方式。它们尽可能从实现细节中删除，因为测试可能如此。

End-to-end tests are also immune to false positives and thus have a good resistance to refactoring. A refactoring, if done correctly, doesn’t change the system’s observable behavior and therefore doesn’t affect the end-to-end tests. That’s another advantage of such tests: they don’t impose any particular implementation. The only thing end-to-end tests look at is how a feature behaves from the end user’s point of view. They are as removed from implementation details as tests could possibly be.

然而，尽管有这些好处，端到端测试有一个主要缺点：它们很慢。任何仅依赖此类测试的系统都很难获得快速反馈。这对许多开发团队来说是一个交易破坏者。这就是为什么几乎不可能只用端到端测试来覆盖你的代码库。

However, despite these benefits, end-to-end tests have a major drawback: they are slow. Any system that relies solely on such tests would have a hard time getting rapid feedback. And that is a deal-breaker for many development teams. This is why it’s pretty much impossible to cover your code base with only end-to-end tests.

图4.6显示了端到端测试在前三个单元测试指标方面的地位。这样的测试可以很好地防止回归错误和误报，但缺乏速度。

Figure 4.6 shows where end-to-end tests stand with regard to the first three unit testing metrics. Such tests provide great protection against both regression errors and false positives, but lack speed.

另一个以牺牲第三个属性为代价最大化三个属性中的两个的例子是一个简单的测试。这样的测试覆盖了一段简单的代码，不太可能破坏，因为它太琐碎了。

Another example of maximizing two out of three attributes at the expense of the third is a trivial test. Such tests cover a simple piece of code, something that is unlikely to break because it’s too trivial.

公共类用户
{
    公共字符串名称 { 得到; 放; }   ❶
}

[事实]
公共无效测试（）
{
    var sut = new User();

    sut.Name = "约翰·史密斯";

    Assert.Equal("John Smith", sut.Name);
}

public class User
{
    public string Name { get; set; }   ❶
}

[Fact]
public void Test()
{
    var sut = new User();

    sut.Name = "John Smith";

    Assert.Equal("John Smith", sut.Name);
}

与端到端测试不同，琐碎的测试确实提供了快速反馈——它们运行得非常快。它们产生误报的可能性也相当低，因此它们对重构有很好的抵抗力。但是，简单的测试不太可能揭示任何回归，因为底层代码中没有太多的错误余地。

Unlike end-to-end tests, trivial tests do provide fast feedback — they run very quickly. They also have a fairly low chance of producing a false positive, so they have good resistance to refactoring. Trivial tests are unlikely to reveal any regressions, though, because there’s not much room for a mistake in the underlying code.

在重言式测试中采用极端结果的琐碎测试。它们不测试任何东西，因为它们的设置方式总是通过或包含语义上无意义的断言。

Trivial tests taken to an extreme result in tautology tests. They don’t test anything because they are set up in such a way that they always pass or contain semantically meaningless assertions.

图4.7显示了简单测试的位置。他们对重构有很好的抵抗力并提供快速反馈，但他们不能保护您免受回归。

Figure 4.7 shows where trivial tests stand. They have good resistance to refactoring and provide fast feedback, but they don’t protect you from regressions.

类似地，很容易编写一个运行速度快并且很有可能捕获回归但会出现大量误报的测试。这样的测试被称为脆性测试：它经不起重构，无论底层功能是否被破坏都会变成红色。

Similarly, it’s pretty easy to write a test that runs fast and has a good chance of catching a regression but does so with a lot of false positives. Such a test is called a brittle test: it can’t withstand a refactoring and will turn red regardless of whether the underlying functionality is broken.

您已经在清单4.2中看到了一个脆弱测试的例子。这是另一个：

You already saw an example of a brittle test in listing 4.2. Here’s another one:

公共类 UserRepository
{
    公共用户 GetById(int id)
    {
        /* ... */
    }

    公共字符串 LastExecutedSqlStatement { 得到; 放; }
}

[事实]
public void GetById_executes_correct_SQL_code()
{
    var sut = new UserRepository();

    用户 user = sut.GetById(5);

    断言.等于(
        "SELECT * FROM dbo.[User] WHERE UserID = 5",
        sut.LastExecutedSqlStatement);
}

public class UserRepository
{
    public User GetById(int id)
    {
        /* ... */
    }

    public string LastExecutedSqlStatement { get; set; }
}

[Fact]
public void GetById_executes_correct_SQL_code()
{
    var sut = new UserRepository();

    User user = sut.GetById(5);

    Assert.Equal(
        "SELECT * FROM dbo.[User] WHERE UserID = 5",
        sut.LastExecutedSqlStatement);
}

此测试确保UserRepository类在从数据库中获取用户时生成正确的 SQL 语句。这个测试能发现错误吗？它可以。例如，开发人员可能会搞乱 SQL 代码生成并错误地使用IDinstead of UserID，测试将通过引发失败来指出这一点。但是这个测试对重构有很好的抵抗力吗？绝对不。以下是导致相同结果的 SQL 语句的不同变体：

This test makes sure the UserRepository class generates a correct SQL statement when fetching a user from the database. Can this test catch a bug? It can. For example, a developer can mess up the SQL code generation and mistakenly use ID instead of UserID, and the test will point that out by raising a failure. But does this test have good resistance to refactoring? Absolutely not. Here are different variations of the SQL statement that lead to the same result:

SELECT * FROM dbo.[User] WHERE UserID = 5
SELECT * FROM dbo.User WHERE UserID = 5
从 dbo 选择用户 ID、姓名、电子邮件。[用户] WHERE UserID = 5
SELECT * FROM dbo.[User] WHERE UserID = @UserID

SELECT * FROM dbo.[User] WHERE UserID = 5
SELECT * FROM dbo.User WHERE UserID = 5
SELECT UserID, Name, Email FROM dbo.[User] WHERE UserID = 5
SELECT * FROM dbo.[User] WHERE UserID = @UserID

如果将 SQL 脚本更改为任何这些变体，清单4.7中的测试将变为红色，即使功能本身将保持运行。这又是一个将测试耦合到 SUT 的内部实现细节的示例。测试的重点是如何而不是什么，因此根植于 SUT 的实现细节，防止任何进一步的重构。

The test in listing 4.7 will turn red if you change the SQL script to any these variations, even though the functionality itself will remain operational. This is once again an example of coupling the test to the SUT’s internal implementation details. The test is focusing on hows instead of whats and thus ingrains the SUT’s implementation details, preventing any further refactoring.

图4.8显示脆性测试属于第三个桶。这样的测试运行速度很快，可以很好地防止回归，但对重构几乎没有抵抗力。

Figure 4.8 shows that brittle tests fall into the third bucket. Such tests run fast and provide good protection against regressions but have little resistance to refactoring.

一个好的单元测试的前三个属性（防止回归、抗重构和快速反馈）是相互排斥的。虽然很容易想出一个最大化这三个属性中的两个的测试，但您只能以牺牲第三个为代价来做到这一点。尽管如此，由于乘法规则，这样的测试将具有接近于零的值。不幸的是，不可能创建一个在所有三个属性上都获得完美分数的理想测试（图4.9）。

The first three attributes of a good unit test (protection against regressions, resistance to refactoring, and fast feedback) are mutually exclusive. While it’s quite easy to come up with a test that maximizes two out of these three attributes, you can only do that at the expense of the third. Still, such a test would have a close-to-zero value due to the multiplication rule. Unfortunately, it’s impossible to create an ideal test that has a perfect score in all three attributes (figure 4.9).

第四个属性，可维护性，与前三个无关，端到端测试除外。端到端测试通常规模较大，因为需要设置此类测试所涉及的所有依赖项。他们还需要额外的努力来保持这些依赖项的运行。因此，端到端测试在维护成本方面往往更加昂贵。

The fourth attribute, maintainability, is not correlated to the first three, with the exception of end-to-end tests. End-to-end tests are normally larger in size because of the necessity to set up all the dependencies such tests reach out to. They also require additional effort to keep those dependencies operational. Hence end-to-end tests tend to be more expensive in terms of maintenance costs.

很难在好的测试的属性之间保持平衡。测试不可能在前三个类别中的每一个类别中都获得最高分，并且您还必须关注可维护性方面，以便测试保持合理的简短。因此，你必须做出取舍。此外，您应该以没有特定属性变为零的方式进行这些权衡。牺牲必须是局部的和战略性的。

It’s hard to keep a balance between the attributes of a good test. A test can’t have the maximum score in each of the first three categories, and you also have to keep an eye on the maintainability aspect so the test remains reasonably short and simple. Therefore, you have to make trade-offs. Moreover, you should make those trade-offs in such a way that no particular attribute turns to zero. The sacrifices have to be partial and strategic.

这些牺牲应该是什么样的？由于防止回归、抵制重构和快速反馈的相互排斥性，您可能认为最好的策略是对每一个做出一点让步：刚好足以为所有三个属性腾出空间。

What should those sacrifices look like? Because of the mutual exclusiveness of protection against regressions, resistance to refactoring, and fast feedback, you may think that the best strategy is to concede a little bit of each: just enough to make room for all three attributes.

但实际上，抵制重构是没有商量余地的。如果您的测试保持相当快并且您不求助于端到端测试的排他性使用，那么您的目标应该是尽可能多地获得它。然后，权衡归结为您的测试在指出错误方面有多好和它们这样做的速度之间的选择：也就是说，在防止回归和快速反馈之间进行选择。您可以将此选择视为一个滑块，可以在防止回归和快速反馈之间自由移动。你在一个属性上获得的越多，你在另一个属性上的损失就越多（见图4.10）。

In reality, though, resistance to refactoring is non-negotiable. You should aim at gaining as much of it as you can, provided that your tests remain reasonably quick and you don’t resort to the exclusive use of end-to-end tests. The trade-off, then, comes down to the choice between how good your tests are at pointing out bugs and how fast they do that: that is, between protection against regressions and fast feedback. You can view this choice as a slider that can be freely moved between protection against regressions and fast feedback. The more you gain in one attribute, the more you lose on the other (see figure 4.10).

拒绝重构的原因是不可协商的，因为测试是否具有此属性主要是二元选择：测试要么拒绝重构，要么不拒绝。中间几乎没有中间阶段。因此，您不能只承认对重构的一点抵制：您将不得不失去它。另一方面，防止回归和快速反馈的指标更具可塑性。在下一节中，您将看到当您选择一个而不是另一个时可以进行什么样的权衡。

The reason resistance to refactoring is non-negotiable is that whether a test possesses this attribute is mostly a binary choice: the test either has resistance to refactoring or it doesn’t. There are almost no intermediate stages in between. Thus you can’t concede just a little resistance to refactoring: you’ll have to lose it all. On the other hand, the metrics of protection against regressions and fast feedback are more malleable. You will see in the next section what kind of trade-offs are possible when you choose one over the other.

	提示
	消除测试中的脆弱性（误报）是通往健壮测试套件的首要任务。 Eradicating brittleness (false positives) in tests is the first priority on the path to a robust test suite.

4.5 探索众所周知的测试自动化概念

4.5  Exploring well-known test automation concepts

测试金字塔是一个提倡在测试套件中按一定比例的不同类型测试的概念（图4.11）：

The Test Pyramid is a concept that advocates for a certain ratio of different types of tests in the test suite (figure 4.11):

测试金字塔通常在视觉上表示为包含这三种类型测试的金字塔。金字塔层的宽度是指套件中特定类型测试的普遍性。层越宽，测试计数越大。层的高度衡量这些测试与模拟最终用户行为的接近程度。端到端测试位于顶部——它们最接近于模仿用户体验。

The Test Pyramid is often represented visually as a pyramid with those three types of tests in it. The width of the pyramid layers refers to the prevalence of a particular type of test in the suite. The wider the layer, the greater the test count. The height of the layer is a measure of how close these tests are to emulating the end user’s behavior. End-to-end tests are at the top — they are the closest to imitating the user experience.

金字塔中不同类型的测试在快速反馈和防止回归之间的权衡中做出不同的选择。较高金字塔层的测试有利于防止回归，而较低层则强调执行速度（图4.12）。

Different types of tests in the pyramid make different choices in the trade-off between fast feedback and protection against regressions. Tests in higher pyramid layers favor protection against regressions, while lower layers emphasize execution speed (figure 4.12).

请注意，这两层都没有放弃对重构的抵抗。自然地，端到端测试和集成测试在此指标上的得分高于单元测试，但这只是作为与生产代码更加分离的副作用。尽管如此，即使是单元测试也不应承认对重构的抵制。所有测试都应旨在产生尽可能少的误报，即使直接使用生产代码也是如此。如何做到这一点是下一章的主题。

Notice that neither layer gives up resistance to refactoring. Naturally, end-to-end and integration tests score higher on this metric than unit tests, but only as a side effect of being more detached from the production code. Still, even unit tests should not concede resistance to refactoring. All tests should aim at producing as few false positives as possible, even when working directly with the production code. How to do that is the topic of the next chapter.

每个团队和项目的测试类型之间的确切组合将有所不同。但总的来说，它应该保持金字塔形状：端到端测试应该是少数；单元测试，大多数；和中间某处的集成测试。

The exact mix between types of tests will be different for each team and project. But in general, it should retain the pyramid shape: end-to-end tests should be the minority; unit tests, the majority; and integration tests somewhere in the middle.

端到端测试占少数的原因再次是 4.4 节中描述的乘法规则。端到端测试在快速反馈指标上得分极低。它们也缺乏可维护性：它们的规模往往更大，需要额外的努力来维护所涉及的进程外依赖性。因此，端到端测试只有在应用于最关键的功能时才有意义——您永远不想看到任何错误的功能——并且只有在您无法通过单元或集成获得相同程度的保护时才有意义测试。对任何其他事物使用端到端测试不应超过您的最低要求值阈值。单元测试通常更平衡，因此通常会有更多单元测试。

The reason end-to-end tests are the minority is, again, the multiplication rule described in section 4.4. End-to-end tests score extremely low on the metric of fast feedback. They also lack maintainability: they tend to be larger in size and require additional effort to maintain the involved out-of-process dependencies. Thus, end-to-end tests only make sense when applied to the most critical functionality — features in which you don’t ever want to see any bugs — and only when you can’t get the same degree of protection with unit or integration tests. The use of end-to-end tests for anything else shouldn’t pass your minimum required value threshold. Unit tests are usually more balanced, and hence you normally have many more of them.

测试金字塔也有例外。例如，如果您的应用程序所做的只是基本的创建、读取、更新和删除 (CRUD) 操作，几乎没有业务规则或任何其他复杂性，那么您的测试“金字塔”很可能看起来像一个具有相同数量单元的矩形和集成测试，没有端到端测试。

There are exceptions to the Test Pyramid. For example, if all your application does is basic create, read, update, and delete (CRUD) operations with very few business rules or any other complexity, your test "pyramid" will most likely look like a rectangle with an equal number of unit and integration tests and no end-to-end tests.

单元测试在没有算法或业务复杂性的情况下用处不大——它们很快就会沦为琐碎的测试。同时，集成测试保留了它们的价值——验证代码如何与其他子系统（如数据库）集成工作仍然很重要，无论它多么简单。结果，您可能会得到更少的单元测试和更多的集成测试。在最简单的例子中，集成测试的数量甚至可能比单元测试的数量更多。

Unit tests are less useful in a setting without algorithmic or business complexity — they quickly descend into trivial tests. At the same time, integration tests retain their value — it’s still important to verify how code, however simple it is, works in integration with other subsystems, such as the database. As a result, you may end up with fewer unit tests and more integration tests. In the most trivial examples, the number of integration tests may even be greater than the number of unit tests.

测试金字塔的另一个例外是一个 API，它延伸到一个进程外依赖项——比如一个数据库。对于这样的应用程序，进行更多的端到端测试可能是一个可行的选择。由于没有用户界面，端到端测试运行得相当快。维护成本也不会太高，因为您只使用单一的外部依赖项，即数据库。基本上，端到端测试与此环境中的集成测试没有区别。唯一不同的是入口点：端到端测试要求将应用程序托管在某个地方以完全模拟最终用户，而集成测试通常在同一进程中托管应用程序。我们将回到第 8 章中的测试金字塔，届时我们将讨论集成测试。

Another exception to the Test Pyramid is an API that reaches out to a single out-of-process dependency — say, a database. Having more end-to-end tests may be a viable option for such an application. Since there’s no user interface, end-to-end tests will run reasonably fast. The maintenance costs won’t be too high, either, because you only work with the single external dependency, the database. Basically, end-to-end tests are indistinguishable from integration tests in this environment. The only thing that differs is the entry point: end-to-end tests require the application to be hosted somewhere to fully emulate the end user, while integration tests normally host the application in the same process. We’ll get back to the Test Pyramid in chapter 8, when we’ll be talking about integration testing.

另一个众所周知的测试自动化概念是黑盒测试与白盒测试。在本节中，我将展示何时使用这两种方法中的每一种：

The other well-known test automation concept is black-box versus white-box testing. In this section, I show when to use each of the two approaches:

这两种方法各有利弊。白盒测试往往更彻底。通过分析源代码，您可以发现许多在仅依赖外部规范时可能会遗漏的错误。另一方面，白盒测试产生的测试通常很脆弱，因为它们往往与被测代码的特定实现紧密耦合。此类测试会产生许多误报，因此不符合重构阻力指标。它们通常也无法追溯到对业务人员有意义的行为，这强烈表明这些测试是脆弱的并且不会增加太多价值。黑盒测试提供了相反的优点和缺点（表4.1）。

There are pros and cons to both of these methods. White-box testing tends to be more thorough. By analyzing the source code, you can uncover a lot of errors that you may miss when relying solely on external specifications. On the other hand, tests resulting from white-box testing are often brittle, as they tend to tightly couple to the specific implementation of the code under test. Such tests produce many false positives and thus fall short on the metric of resistance to refactoring. They also often can’t be traced back to a behavior that is meaningful to a business person, which is a strong sign that these tests are fragile and don’t add much value. Black-box testing provides the opposite set of pros and cons (table 4.1).

您可能还记得第 4.4.5 节中提到的，您不能在重构阻力上妥协：测试要么具有重构阻力，要么没有。因此，默认选择黑盒测试而不是白盒测试。进行所有测试——无论是单元测试、集成测试还是端到端测试——将系统视为黑匣子，并验证对问题域有意义的行为。如果您无法将测试追溯到业务需求，则表明测试很脆弱。重组或删除此测试；不要让它按原样进入套房。唯一的例外是当测试涵盖具有高算法复杂性的实用程序代码时（第 7 章对此有更多介绍）。

As you may remember from section 4.4.5, you can’t compromise on resistance to refactoring: a test either possesses resistance to refactoring or it doesn’t. Therefore, choose black-box testing over white-box testing by default. Make all tests — be they unit, integration, or end-to-end — view the system as a black box and verify behavior meaningful to the problem domain. If you can’t trace a test back to a business requirement, it’s an indication of the test’s brittleness. Either restructure or delete this test; don’t let it into the suite as is. The only exception is when the test covers utility code with high algorithmic complexity (more on this in chapter 7).

请注意，尽管在编写测试时最好使用黑盒测试，但在分析测试时仍然可以使用白盒方法。使用代码覆盖工具查看哪些代码分支没有被执行，然后像对代码的内部结构一无所知一样转身测试它们。这种白盒和黑盒方法的组合效果最好。

Note that even though black-box testing is preferable when writing tests, you can still use the white-box method when analyzing the tests. Use code coverage tools to see which code branches are not exercised, but then turn around and test them as if you know nothing about the code’s internal structure. Such a combination of the white-box and black-box methods works best.

4.6 总结

4.6  Summary

• 一个好的单元测试有四个基本属性，您可以使用它们来分析任何自动化测试，无论是单元测试、集成测试还是端到端测试：

  • 防止回归

  • 抵制重构

  • 快速反馈

  • 可维护性

• A good unit test has four foundational attributes that you can use to analyze any automated test, whether unit, integration, or end-to-end:

  • Protection against regressions

  • Resistance to refactoring

  • Fast feedback

  • Maintainability

• 防止回归是衡量测试在指示错误（回归）存在方面有多好。测试执行的代码越多（您的代码以及项目中使用的库和框架的代码），该测试揭示错误的可能性就越大。

• Protection against regressions is a measure of how good the test is at indicating the presence of bugs (regressions). The more code the test executes (both your code and the code of libraries and frameworks used in the project), the higher the chance this test will reveal a bug.

• 重构阻力是指测试在不产生误报的情况下维持应用程序代码重构的程度。

• Resistance to refactoring is the degree to which a test can sustain application code refactoring without producing a false positive.

• 误报是误报——表明测试失败的结果，而它涵盖的功能按预期工作。误报会对测试套件产生毁灭性的影响：

  • 它们削弱了您对代码中的问题做出反应的能力和意愿，因为您已经习惯了误报并不再关注它们。

  • 它们削弱了您对测试作为可靠安全网的看法，并导致对测试套件失去信任。

• A false positive is a false alarm — a result indicating that the test fails, whereas the functionality it covers works as intended. False positives can have a devastating effect on the test suite:

  • They dilute your ability and willingness to react to problems in code, because you get accustomed to false alarms and stop paying attention to them.

  • They diminish your perception of tests as a reliable safety net and lead to losing trust in the test suite.

• 误报是测试与被测系统的内部实现细节之间紧密耦合的结果。为避免这种耦合，测试必须验证 SUT 产生的最终结果，而不是验证它所采取的步骤。

• False positives are a result of tight coupling between tests and the internal implementation details of the system under test. To avoid such coupling, the test must verify the end result the SUT produces, not the steps it took to do that.

• 防止回归和抵制重构有助于提高测试准确性。一个测试是准确的，因为它产生了一个强烈的信号（能够发现错误，防止回归的范围）和尽可能少的噪音（误报）（重构的阻力范围）。

• Protection against regressions and resistance to refactoring contribute to test accuracy. A test is accurate insofar as it generates a strong signal (is capable of finding bugs, the sphere of protection against regressions) with as little noise (false positives) as possible (the sphere of resistance to refactoring).

• 误报在项目开始时并没有那么大的负面影响，但随着项目的发展它们变得越来越重要：与误报（未注意到的错误）一样重要。

• False positives don’t have as much of a negative effect in the beginning of the project, but they become increasingly important as the project grows: as important as false negatives (unnoticed bugs).

• 快速反馈衡量测试执行的速度。

• Fast feedback is a measure of how quickly the test executes.

• 可维护性由两部分组成：

  • 理解测试有多难。测试越小，它的可读性就越高。

  • 运行测试有多困难。测试涉及的进程外依赖项越少，就越容易保持它们的可操作性。

• Maintainability consists of two components:

  • How hard it is to understand the test. The smaller the test, the more readable it is.

  • How hard it is to run the test. The fewer out-of-process dependencies the test reaches out to, the easier it is to keep them operational.

• 测试的价值估计是测试在四个属性中的每一个中获得的分数的乘积。如果测试在其中一个属性中为零，则其值也变为零。

• A test’s value estimate is the product of scores the test gets in each of the four attributes. If the test gets zero in one of the attributes, its value turns to zero as well.

• 不可能创建一个在所有四个属性中都获得最高分的测试，因为前三个属性—— 防止回归、抵抗重构和快速反馈 ——是相互排斥的。该测试只能最大化三个中的两个。

• It’s impossible to create a test that gets the maximum score in all four attributes, because the first three — protection against regressions, resistance to refactoring, and fast feedback — are mutually exclusive. The test can only maximize two out of the three.

• 抵制重构是没有商量余地的，因为测试是否具有此属性主要是二元选择：测试要么抵制重构，要么不抵制。属性之间的权衡归结为防止回归和快速反馈之间的选择。

• Resistance to refactoring is non-negotiable because whether a test possess this attribute is mostly a binary choice: the test either has resistance to refactoring or it doesn’t. The trade-off between the attributes comes down to the choice between protection against regressions and fast feedback.

• 测试金字塔提倡单元测试、集成测试和端到端测试按一定比例进行：端到端测试应该占少数，单元测试占多数，集成测试居中。

• The Test Pyramid advocates for a certain ratio of unit, integration, and end-to-end tests: end-to-end tests should be in the minority, unit tests in the majority, and integration tests somewhere in the middle.

• 金字塔中不同类型的测试在快速反馈和防止回归之间做出不同的选择。端到端测试有利于防止回归，而单元测试有利于快速反馈。

• Different types of tests in the pyramid make different choices between fast feedback and protection against regressions. End-to-end tests favor protection against regressions, while unit tests favor fast feedback.

• 编写测试时使用黑盒测试方法。分析测试时使用白盒方法。

• Use the black-box testing method when writing tests. Use the white-box method when analyzing the tests.

5.2 可观察行为与实现细节

5.2  Observable behavior vs. implementation details

所有生产代码都可以按两个维度进行分类：

All production code can be categorized along two dimensions:

这些维度中的类别不重叠。一个方法不能同时属于公共 API 和私有 API；它是一个或另一个。同样，代码要么是内部实现细节，要么是系统可观察行为的一部分，但不能同时是两者。

The categories in these dimensions don’t overlap. A method can’t belong to both a public and a private API; it’s either one or the other. Similarly, the code is either an internal implementation detail or part of the system’s observable behavior, but not both.

大多数编程语言都提供了一种简单的机制来区分代码库的公共 API 和私有 API。例如，在 C# 中，您可以用关键字标记类中的任何成员private，该成员将从客户端代码中隐藏，成为该类私有 API 的一部分。类也是如此：您可以使用privateorinternal关键字轻松地将它们设为私有。

Most programming languages provide a simple mechanism to differentiate between the code base’s public and private APIs. For example, in C#, you can mark any member in a class with the private keyword, and that member will be hidden from the client code, becoming part of the class’s private API. The same is true for classes: you can easily make them private by using the private or internal keyword.

可观察行为和内部实现细节之间的区别更加细微。要使一段代码成为系统可观察行为的一部分，它必须执行以下操作之一：

The distinction between observable behavior and internal implementation details is more nuanced. For a piece of code to be part of the system’s observable behavior, it has to do one of the following things:

任何不做这两件事的代码都是实现细节。

Any code that does neither of these two things is an implementation detail.

请注意，代码是否是可观察的行为取决于它的客户是谁以及该客户的目标是什么。为了成为可观察行为的一部分，代码需要与至少一个这样的目标有直接联系。根据代码所在的位置，客户端一词可以指代不同的事物。常见示例是来自相同代码库的客户端代码、外部应用程序或用户界面。

Notice that whether the code is observable behavior depends on who its client is and what the goals of that client are. In order to be a part of observable behavior, the code needs to have an immediate connection to at least one such goal. The word client can refer to different things depending on where the code resides. The common examples are client code from the same code base, an external application, or the user interface.

理想情况下，系统的公共 API 表面应与其可观察的行为一致，并且其所有实现细节都应隐藏在客户的视线之外。这样的系统有一个设计良好的API（图5.4）。

Ideally, the system’s public API surface should coincide with its observable behavior, and all its implementation details should be hidden from the eyes of the clients. Such a system has a well-designed API (figure 5.4).

但是，系统的公共 API 通常会超出其可观察的行为，并开始公开实现细节。这样一个系统的实现细节会泄露到它的公共 API 表面（图5.5）。

Often, though, the system’s public API extends beyond its observable behavior and starts exposing implementation details. Such a system’s implementation details leak to its public API surface (figure 5.5).

让我们看一下实现细节泄露到公共 API 的代码示例。清单5.5显示了一个User具有公共 API 的类，该 API 由两个成员组成：一个Name属性和一个NormalizeName()方法。该类还有一个不变量：用户名不得超过 50 个字符，否则应被截断。

Let’s take a look at examples of code whose implementation details leak to the public API. Listing 5.5 shows a User class with a public API that consists of two members: a Name property and a NormalizeName() method. The class also has an invariant: users' names must not exceed 50 characters and should be truncated otherwise.

公共类用户
{
    公共字符串名称 { 得到; 放; }

    公共字符串 NormalizeName（字符串名称）
    {
        string result = (name ?? "").Trim();

        如果（结果。长度> 50）
            返回结果.Substring(0, 50);

        返回结果；
    }
}

公共类用户控制器
{
    public void RenameUser(int userId, string newName)
    {
        用户 user = GetUserFromDatabase(userId);

        string normalizedName = user.NormalizeName(newName);
        user.Name = normalizedName;

        保存用户到数据库（用户）；
    }
}

public class User
{
    public string Name { get; set; }

    public string NormalizeName(string name)
    {
        string result = (name ?? "").Trim();

        if (result.Length > 50)
            return result.Substring(0, 50);

        return result;
    }
}

public class UserController
{
    public void RenameUser(int userId, string newName)
    {
        User user = GetUserFromDatabase(userId);

        string normalizedName = user.NormalizeName(newName);
        user.Name = normalizedName;

        SaveUserToDatabase(user);
    }
}

UserController是客户端代码。User它在其方法中使用该类RenameUser。您可能已经猜到，此方法的目标是更改用户名。

UserController is client code. It utilizes the User class in its RenameUser method. The goal of this method, as you have probably guessed, is to change a user’s name.

那么，为什么User的 API 设计不佳？再看看它的成员：Name属性和NormalizeName方法。两者都是公开的。因此，为了使类的 API 设计良好，这些成员应该是可观察行为的一部分。这反过来又要求他们做以下两件事之一（为方便起见，我在这里重复）：

So, why isn’t User's API well-designed? Look at its members once again: the Name property and the NormalizeName method. Both of them are public. Therefore, in order for the class’s API to be well-designed, these members should be part of the observable behavior. This, in turn, requires them to do one of the following two things (which I’m repeating here for convenience):

只有该Name物业符合此要求。它公开了一个设置器，这是一个允许UserController实现更改用户名的目标的操作。该NormalizeName方法也是一种操作，但它与客户的目标没有直接联系。调用此方法的唯一原因UserController是为了满足 的不变性User。NormalizeName因此是泄漏到类的公共 API 的实现细节（图5.6）。

Only the Name property meets this requirement. It exposes a setter, which is an operation that allows UserController to achieve its goal of changing a user’s name. The NormalizeName method is also an operation, but it doesn’t have an immediate connection to the client’s goal. The only reason UserController calls this method is to satisfy the invariant of User. NormalizeName is therefore an implementation detail that leaks to the class’s public API (figure 5.6).

为了解决这个问题并使类的 API 设计良好，User需要隐藏NormalizeName()它并将其作为属性设置器的一部分在内部调用，而不依赖于客户端代码来这样做。下面的清单显示了这种方法。

To fix the situation and make the class’s API well-designed, User needs to hide NormalizeName() and call it internally as part of the property’s setter without relying on the client code to do so. The following listing shows this approach.

公共类用户
{
    私有字符串_name；
    公共字符串名称
    {
        得到 => _名称；
        设置 => _name = NormalizeName(value);
    }

    私有字符串 NormalizeName（字符串名称）
    {
        string result = (name ?? "").Trim();

        如果（结果。长度> 50）
            返回结果.Substring(0, 50);

        返回结果；
    }
}

公共类用户控制器
{
    public void RenameUser(int userId, string newName)
    {
        用户 user = GetUserFromDatabase(userId);
        user.Name = newName;
        保存用户到数据库（用户）；
    }
}

public class User
{
    private string _name;
    public string Name
    {
        get => _name;
        set => _name = NormalizeName(value);
    }

    private string NormalizeName(string name)
    {
        string result = (name ?? "").Trim();

        if (result.Length > 50)
            return result.Substring(0, 50);

        return result;
    }
}

public class UserController
{
    public void RenameUser(int userId, string newName)
    {
        User user = GetUserFromDatabase(userId);
        user.Name = newName;
        SaveUserToDatabase(user);
    }
}

User清单5.6中的 API设计良好：只有可观察的行为（Name属性）是公开的，而实现细节（方法NormalizeName）隐藏在私有 API 后面（图5.7）。

User's API in listing 5.6 is well-designed: only the observable behavior (the Name property) is made public, while the implementation details (the NormalizeName method) are hidden behind the private API (figure 5.7).

V03严格来说，Name的 getter 也应该设为私有，因为它不被UserController. 但实际上，您几乎总是想回读您所做的更改。因此，在实际项目中，肯定会有另一种用例需要通过Namegetter 来查看用户的当前名称。

V03Strictly speaking, Name's getter should also be made private, because it’s not used by UserController. In reality, though, you almost always want to read back changes you make. Therefore, in a real project, there will certainly be another use case that requires seeing users' current names via Name's getter.

有一个很好的经验法则可以帮助您确定一个类是否泄露了它的实现细节。如果客户端为实现单个目标而必须在类上调用的操作数大于一个，则该类很可能会泄漏实现细节。理想情况下，任何个人目标都应该通过一次操作来实现。例如，在清单5.5UserController中，必须使用两个操作User：

There’s a good rule of thumb that can help you determine whether a class leaks its implementation details. If the number of operations the client has to invoke on the class to achieve a single goal is greater than one, then that class is likely leaking implementation details. Ideally, any individual goal should be achieved with a single operation. In listing 5.5, for example, UserController has to use two operations from User:

string normalizedName = user.NormalizeName(newName);
user.Name = normalizedName;

string normalizedName = user.NormalizeName(newName);
user.Name = normalizedName;

重构后，操作数减少为一个：

After the refactoring, the number of operations has been reduced to one:

user.Name = newName;

user.Name = newName;

根据我的经验，这条经验法则适用于涉及业务逻辑的绝大多数情况。不过，很可能会有例外。尽管如此，请务必检查您的代码违反此规则的每种情况，以防止可能泄露实施细节。

In my experience, this rule of thumb holds true for the vast majority of cases where business logic is involved. There could very well be exceptions, though. Still, be sure to examine each situation where your code violates this rule for a potential leak of implementation details.

维护设计良好的 API 与封装的概念有关。您可能还记得第 3 章，封装是保护您的代码免受不一致影响的行为，也称为不变违规。不变量是应该始终成立的条件。上一示例中的类User有一个这样的不变量：任何用户的名称都不能超过 50 个字符。

Maintaining a well-designed API relates to the notion of encapsulation. As you might recall from chapter 3, encapsulation is the act of protecting your code against inconsistencies, also known as invariant violations. An invariant is a condition that should be held true at all times. The User class from the previous example had one such invariant: no user could have a name that exceeded 50 characters.

公开实现细节与不变违规密切相关——前者通常会导致后者。原始版本不仅User泄露了其实现细节，而且也没有保持适当的封装。它允许客户端绕过不变量并为用户分配一个新名称，而无需首先对该名称进行规范化。

Exposing implementation details goes hand in hand with invariant violations — the former often leads to the latter. Not only did the original version of User leak its implementation details, but it also didn’t maintain proper encapsulation. It allowed the client to bypass the invariant and assign a new name to a user without normalizing that name first.

从长远来看，封装对于代码库的可维护性至关重要。原因是复杂性。代码复杂性是您在软件开发中将面临的最大挑战之一。代码库变得越复杂，使用起来就越困难，这反过来又会导致开发速度减慢并增加错误数量。

Encapsulation is crucial for code base maintainability in the long run. The reason is complexity. Code complexity is one of the biggest challenges you’ll face in software development. The more complex the code base becomes, the harder it is to work with, which, in turn, results in slowing down development speed and increasing the number of bugs.

没有封装，您就没有实用的方法来应对不断增加的代码复杂性。当代码的 API 没有指导您了解该代码允许做什么和不允许做什么时，您必须牢记大量信息，以确保您不会引入与新代码更改的不一致。这给编程的过程带来了额外的精神负担。尽可能多地减轻自己的负担。你不能相信自己总是做正确的事——所以，消除做错事的可能性。这样做的最佳方法是保持适当的封装，这样您的代码库甚至不会为您提供错误执行任何操作的选项。封装最终服务于与单元测试相同的目标：它使您的软件项目可持续增长。

Without encapsulation, you have no practical way to cope with ever-increasing code complexity. When the code’s API doesn’t guide you through what is and what isn’t allowed to do with that code, you have to keep a lot of information in mind to make sure you don’t introduce inconsistencies with new code changes. This brings an additional mental burden to the process of programming. Remove as much of that burden from yourself as possible. You cannot trust yourself to do the right thing all the time — so, eliminate the very possibility of doing the wrong thing. The best way to do so is to maintain proper encapsulation so that your code base doesn’t even provide an option for you to do anything incorrectly. Encapsulation ultimately serves the same goal as unit testing: it enables sustainable growth of your software project.

有一个类似的原则：告诉不要问。它由 Martin Fowler ( https://martinfowler.com/bliki/TellDontAsk.html )创造，代表将数据与操作该数据的函数捆绑在一起。您可以将此原则视为封装实践的必然结果。代码封装是一个目标，而将数据和函数捆绑在一起以及隐藏实现细节是实现该目标的手段：

There’s a similar principle: tell-don’t-ask. It was coined by Martin Fowler (https://martinfowler.com/bliki/TellDontAsk.html) and stands for bundling data with the functions that operate on that data. You can view this principle as a corollary to the practice of encapsulation. Code encapsulation is a goal, whereas bundling data and functions together, as well as hiding implementation details, are the means to achieve that goal:

清单5.5中显示的示例演示了一个操作（NormalizeName方法），该操作是泄漏到公共 API 的实现细节。让我们再看一个带有状态的例子。下面的清单包含MessageRenderer您在第 4 章中看到的类。它使用子呈现器的集合来生成消息的 HTML 表示形式，其中包含标题、正文和页脚。

The example shown in listing 5.5 demonstrated an operation (the NormalizeName method) that was an implementation detail leaking to the public API. Let’s also look at an example with state. The following listing contains the MessageRenderer class you saw in chapter 4. It uses a collection of sub-renderers to generate an HTML representation of a message containing a header, a body, and a footer.

公共类 MessageRenderer : IRenderer
{
    public IReadOnlyList<IRenderer> SubRenderers { get; }

    公共 MessageRenderer()
    {
        SubRenderers = new List<IRenderer>
        {
            新的 HeaderRenderer(),
            新的身体渲染器（），
            新的 FooterRenderer()
        };
    }

    公共字符串渲染（消息消息）
    {
        返回子渲染器
            .Select(x => x.Render(message))
            .Aggregate("", (str1, str2) => str1 + str2);
    }
}

public class MessageRenderer : IRenderer
{
    public IReadOnlyList<IRenderer> SubRenderers { get; }

    public MessageRenderer()
    {
        SubRenderers = new List<IRenderer>
        {
            new HeaderRenderer(),
            new BodyRenderer(),
            new FooterRenderer()
        };
    }

    public string Render(Message message)
    {
        return SubRenderers
            .Select(x => x.Render(message))
            .Aggregate("", (str1, str2) => str1 + str2);
    }
}

子渲染器集合是公开的。但它是可观察行为的一部分吗？假设客户端的目标是呈现 HTML 消息，答案是否定的。这样的客户唯一需要的类成员是Render方法本身。因此SubRenderers也是一个泄漏的实现细节。

The sub-renderers collection is public. But is it part of observable behavior? Assuming that the client’s goal is to render an HTML message, the answer is no. The only class member such a client would need is the Render method itself. Thus SubRenderers is also a leaking implementation detail.

我再次提到这个例子是有原因的。您可能还记得，我用它来说明脆性测试。该测试之所以脆弱，恰恰是因为它与此实现细节相关联——它检查集合的组成。通过在该方法中重新定位测试来修复脆性Render。新版本的测试验证了生成的消息——客户端代码唯一关心的输出，即可观察到的行为。

I bring up this example again for a reason. As you may remember, I used it to illustrate a brittle test. That test was brittle precisely because it was tied to this implementation detail — it checked to see the collection’s composition. The brittleness was fixed by re-targeting the test at the Render method. The new version of the test verified the resulting message — the only output the client code cared about, the observable behavior.

如您所见，良好的单元测试与设计良好的 API 之间存在内在联系。通过将所有实现细节设为私有，您的测试别无选择，只能验证代码的可观察行为，这会自动提高它们对重构的抵抗力。

As you can see, there’s an intrinsic connection between good unit tests and a well-designed API. By making all implementation details private, you leave your tests no choice other than to verify the code’s observable behavior, which automatically improves their resistance to refactoring.

	提示
	使 API 设计良好会自动改进单元测试。 Making the API well-designed automatically improves unit tests.

另一条准则源自设计良好的 API 的定义：您应该公开最少数量的操作和状态。只有直接帮助客户实现目标的代码才应该公开。其他一切都是实现细节，因此必须隐藏在私有 API 后面。

Another guideline flows from the definition of a well-designed API: you should expose the absolute minimum number of operations and state. Only code that directly helps clients achieve their goals should be made public. Everything else is implementation details and thus must be hidden behind the private API.

请注意，不存在泄漏可观察行为这样的问题，这与泄漏实现细节的问题是对称的。虽然您可以公开实现细节（客户端不应使用的方法或类），但您无法隐藏可观察到的行为。这样的方法或类将不再与客户目标有直接联系，因为客户将无法再直接使用它。因此，根据定义，此代码将不再是可观察行为的一部分。表5.1总结了这一切。

Note that there’s no such problem as leaking observable behavior, which would be symmetric to the problem of leaking implementation details. While you can expose an implementation detail (a method or a class that is not supposed to be used by the client), you can’t hide an observable behavior. Such a method or class would no longer have an immediate connection to the client goals, because the client wouldn’t be able to directly use it anymore. Thus, by definition, this code would cease to be part of observable behavior. Table 5.1 sums it all up.

5.3 mocks与测试脆弱性的关系

5.3  The relationship between mocks and test fragility

一个典型的应用程序由两层组成，领域和应用服务，如图5.8所示。域层位于图的中间，因为它是应用程序的中心部分。它包含业务逻辑：构建应用程序的基本功能。领域层及其业务逻辑将此应用程序与其他应用程序区分开来，并为组织提供竞争优势。

A typical application consists of two layers, domain and application services, as shown in figure 5.8. The domain layer resides in the middle of the diagram because it’s the central part of your application. It contains the business logic: the essential functionality your application is built for. The domain layer and its business logic differentiate this application from others and provide a competitive advantage for the organization.

应用服务层位于领域层之上，协调该层与外部世界之间的通信。例如，如果您的应用程序是一个 RESTful API，则对该 API 的所有请求都会首先到达应用程序服务层。该层然后协调域类和进程外依赖项之间的工作。下面是应用程序服务的此类协调示例。它执行以下操作：

The application services layer sits on top of the domain layer and orchestrates communication between that layer and the external world. For example, if your application is a RESTful API, all requests to this API hit the application services layer first. This layer then coordinates the work between domain classes and out-of-process dependencies. Here’s an example of such coordination for the application service. It does the following:

应用服务层和领域层的组合形成一个六边形，它本身代表你的应用。它可以与其他应用程序交互，这些应用程序用自己的六边形表示（见图5.9）。这些其他应用程序可以是 SMTP 服务、第三方系统、消息总线等。一组相互作用的六边形构成了一个六边形建筑。

The combination of the application services layer and the domain layer forms a hexagon, which itself represents your application. It can interact with other applications, which are represented with their own hexagons (see figure 5.9). These other applications could be an SMTP service, a third-party system, a message bus, and so on. A set of interacting hexagons makes up a hexagonal architecture.

六边形建筑一词是由 Alistair Cockburn 提出的。其目的是强调三个重要的指导方针：

The term hexagonal architecture was introduced by Alistair Cockburn. Its purpose is to emphasize three important guidelines:

应用程序的每一层都表现出可观察的行为，并包含自己的一组实现细节。例如，领域层的可观察行为是该层的操作和状态的总和，这些操作和状态有助于应用程序服务层至少实现其目标之一。设计良好的 API 的原则具有分形性：它们同样适用于整个层或单个类。

Each layer of your application exhibits observable behavior and contains its own set of implementation details. For example, observable behavior of the domain layer is the sum of this layer’s operations and state that helps the application service layer achieve at least one of its goals. The principles of a well-designed API have a fractal nature: they apply equally to as much as a whole layer or as little as a single class.

当你对每一层的 API 进行了良好的设计（即隐藏其实现细节）时，你的测试也开始具有分形结构；他们验证有助于实现相同目标但处于不同级别的行为。涵盖应用程序服务的测试会检查该服务如何实现外部客户端提出的总体、粗粒度目标。同时，与领域类一起工作的测试验证了作为更大目标一部分的子目标（图5.10）。

When you make each layer’s API well-designed (that is, hide its implementation details), your tests also start to have a fractal structure; they verify behavior that helps achieve the same goals but at different levels. A test covering an application service checks to see how this service attains an overarching, coarse-grained goal posed by the external client. At the same time, a test working with a domain class verifies a subgoal that is part of that greater goal (figure 5.10).

您可能还记得在前面的章节中我是如何提到您应该能够将任何测试追溯到特定的业务需求。每个测试都应该讲述一个对领域专家有意义的故事，如果没有，则强烈表明测试耦合到实现细节，因此很脆弱。我希望现在你能明白为什么。

You might remember from previous chapters how I mentioned that you should be able to trace any test back to a particular business requirement. Each test should tell a story that is meaningful to a domain expert, and if it doesn’t, that’s a strong indication that the test couples to implementation details and therefore is brittle. I hope now you can see why.

可观察到的行为从外层向内流动到中心。外部客户提出的总体目标被转化为由各个领域类实现的子目标。因此，域层中的每个可观察行为都保留了与特定业务用例的联系。您可以从最内层（域）层向外递归地跟踪此连接到应用程序服务层，然后再到外部客户端的需求。这种可追溯性遵循可观察行为的定义。要使一段代码成为可观察行为的一部分，它需要帮助客户实现其目标之一。对于领域类，客户端是一个应用服务；对于应用程序服务，它是外部客户端本身。

Observable behavior flows inward from outer layers to the center. The overarching goal posed by the external client gets translated into subgoals achieved by individual domain classes. Each piece of observable behavior in the domain layer therefore preserves the connection to a particular business use case. You can trace this connection recursively from the innermost (domain) layer outward to the application services layer and then to the needs of the external client. This traceability follows from the definition of observable behavior. For a piece of code to be part of observable behavior, it needs to help the client achieve one of its goals. For a domain class, the client is an application service; for the application service, it’s the external client itself.

使用设计良好的 API 验证代码库的测试也与业务需求有关，因为这些测试仅与可观察到的行为相关。一个很好的例子是清单5.6User中的和类（为方便起见，我在这里重复代码）。UserController

Tests that verify a code base with a well-designed API also have a connection to business requirements because those tests tie to the observable behavior only. A good example is the User and UserController classes from listing 5.6 (I’m repeating the code here for convenience).

公共类用户
{
    私有字符串_name；
    公共字符串名称
    {
        得到 => _名称；
        设置 => _name = NormalizeName(value);
    }

    私有字符串 NormalizeName（字符串名称）
    {
        /* 将名称缩减为 50 个字符 */
    }
}

公共类用户控制器
{
    public void RenameUser(int userId, string newName)
    {
        用户 user = GetUserFromDatabase(userId);
        user.Name = newName;
        保存用户到数据库（用户）；
    }
}

public class User
{
    private string _name;
    public string Name
    {
        get => _name;
        set => _name = NormalizeName(value);
    }

    private string NormalizeName(string name)
    {
        /* Trim name down to 50 characters */
    }
}

public class UserController
{
    public void RenameUser(int userId, string newName)
    {
        User user = GetUserFromDatabase(userId);
        user.Name = newName;
        SaveUserToDatabase(user);
    }
}

UserController在这个例子中是一个应用程序服务。假设外部客户端并没有规范化用户名的特定目标，并且完全由于应用程序本身的限制而对所有名称进行规范化，则类NormalizeName中的方法User无法追溯到客户端的需求。因此，它是一个实现细节，应该私有化（我们在本章前面已经这样做了）。此外，测试不应直接检查此方法。他们应该只将它作为类的可观察行为的一部分进行验证——Name在这个例子中是属性的设置器。

UserController in this example is an application service. Assuming that the external client doesn’t have a specific goal of normalizing user names, and all names are normalized solely due to restrictions from the application itself, the NormalizeName method in the User class can’t be traced to the client’s needs. Therefore, it’s an implementation detail and should be made private (we already did that earlier in this chapter). Moreover, tests shouldn’t check this method directly. They should verify it only as part of the class’s observable behavior — the Name property’s setter in this example.

这种始终根据业务需求跟踪代码库的公共 API 的准则适用于绝大多数领域类和应用程序服务，但不太适用于实用程序和基础设施代码。此类代码解决的个别问题通常过于低级和细粒度，无法追溯到特定的业务用例。

This guideline of always tracing the code base’s public API to business requirements applies to the vast majority of domain classes and application services but less so to utility and infrastructure code. The individual problems such code solves are often too low-level and fine-grained and can’t be traced to a specific business use case.

典型应用中有两种类型的通信：系统内和系统间。系统内通信是应用程序内部类之间的通信。系统间通信是指您的应用程序与其他应用程序对话（图5.11）。

There are two types of communications in a typical application: intra-system and inter-system. Intra-system communications are communications between classes inside your application. Inter-system communications are when your application talks to other applications (figure 5.11).

V03系统内通信是实现细节；系统间通信不是。

V03Intra-system communications are implementation details; inter-system communications are not.

系统内通信是实现细节，因为您的域类为执行操作而进行的协作不是它们可观察行为的一部分。这些合作与客户的目标没有直接联系。因此，耦合到此类协作会导致脆弱的测试。

Intra-system communications are implementation details because the collaborations your domain classes go through in order to perform an operation are not part of their observable behavior. These collaborations don’t have an immediate connection to the client’s goal. Thus, coupling to such collaborations leads to fragile tests.

系统间通信是另一回事。与应用程序内部类之间的协作不同，系统与外部世界对话的方式形成了整个系统的可观察行为。它是您的应用程序必须始终持有的合同的一部分（图5.12）。

Inter-system communications are a different matter. Unlike collaborations between classes inside your application, the way your system talks to the external world forms the observable behavior of that system as a whole. It’s part of the contract your application must hold at all times (figure 5.12).

系统间通信的这一属性源于单独的应用程序共同发展的方式。这种演变的主要原则之一是保持向后兼容性。无论您在系统内部执行何种重构，它用于与外部应用程序对话的通信模式都应始终保持不变，以便外部应用程序能够理解它。例如，您的应用程序在总线上发出的消息应保留其结构，向 SMTP 服务发出的调用应具有相同数量和类型的参数，等等。

This attribute of inter-system communications stems from the way separate applications evolve together. One of the main principles of such an evolution is maintaining backward compatibility. Regardless of the refactorings you perform inside your system, the communication pattern it uses to talk to external applications should always stay in place, so that external applications can understand it. For example, messages your application emits on a bus should preserve their structure, the calls issued to an SMTP service should have the same number and type of parameters, and so on.

在验证系统和外部应用程序之间的通信模式时，使用模拟是有益的。相反，使用模拟来验证系统内部类之间的通信会导致测试与实现细节相结合，因此不符合重构阻力指标。

The use of mocks is beneficial when verifying the communication pattern between your system and external applications. Conversely, using mocks to verify communications between classes inside your system results in tests that couple to implementation details and therefore fall short of the resistance-to-refactoring metric.

为了说明系统内和系统间通信之间的区别，我将使用我在第 2 章和本章前面使用的Customer和类来扩展示例。Store想象一下以下业务用例：

To illustrate the difference between intra-system and inter-system communications, I’ll expand on the example with the Customer and Store classes that I used in chapter 2 and earlier in this chapter. Imagine the following business use case:

我们还假设该应用程序是一个没有用户界面的 API。

Let’s also assume that the application is an API with no user interface.

在下面的清单中，该类是一个应用程序服务，它协调域类（ 、、）和外部应用程序（，它是 SMTP 服务的代理）CustomerController之间的工作。CustomerProductStoreEmailGateway

In the following listing, the CustomerController class is an application service that orchestrates the work between domain classes (Customer, Product, Store) and the external application (EmailGateway, which is a proxy to an SMTP service).

公共类 CustomerController
{
    public bool Purchase(int customerId, int productId, int quantity)
    {
        客户 customer = _customerRepository.GetById(customerId);
        产品 product = _productRepository.GetById(productId);

        bool isSuccess = customer.Purchase(
            _mainStore、产品、数量）；

        如果（成功）
        {
            _emailGateway.SendReceipt(
                customer.Email, product.Name, quantity);
        }

        返回成功；
    }
}

public class CustomerController
{
    public bool Purchase(int customerId, int productId, int quantity)
    {
        Customer customer = _customerRepository.GetById(customerId);
        Product product = _productRepository.GetById(productId);

        bool isSuccess = customer.Purchase(
            _mainStore, product, quantity);

        if (isSuccess)
        {
            _emailGateway.SendReceipt(
                customer.Email, product.Name, quantity);
        }

        return isSuccess;
    }
}

为简洁起见，省略了输入参数的验证。在该Purchase方法中，客户检查商店中是否有足够的库存，如果足够，则减少产品数量。

Validation of input parameters is omitted for brevity. In the Purchase method, the customer checks to see if there’s enough inventory in the store and, if so, decreases the product amount.

进行购买的行为是具有系统内和系统间通信的业务用例。系统间通信是CustomerController应用程序服务与两个外部系统之间的通信：第三方应用程序（也是启动用例的客户端）和电子邮件网关。系统内通信发生在域类Customer和Store域类之间（图5.13）。

The act of making a purchase is a business use case with both intra-system and inter-system communications. The inter-system communications are those between the CustomerController application service and the two external systems: the third-party application (which is also the client initiating the use case) and the email gateway. The intra-system communication is between the Customer and the Store domain classes (figure 5.13).

在此示例中，对 SMTP 服务的调用是对外部世界可见的副作用，因此形成了整个应用程序的可观察行为。它还与客户的目标直接相关。应用的客户端是第三方系统。该系统的目标是进行购买，它希望客户收到确认电子邮件作为成功结果的一部分。

In this example, the call to the SMTP service is a side effect that is visible to the external world and thus forms the observable behavior of the application as a whole. It also has a direct connection to the client’s goals. The client of the application is the third-party system. This system’s goal is to make a purchase, and it expects the customer to receive a confirmation email as part of the successful outcome.

调用 SMTP 服务是进行模拟的正当理由。它不会导致测试脆弱性，因为您希望确保这种类型的通信即使在重构之后也能保持原样。使用模拟可以帮助您做到这一点。

The call to the SMTP service is a legitimate reason to do mocking. It doesn’t lead to test fragility because you want to make sure this type of communication stays in place even after refactoring. The use of mocks helps you do exactly that.

下一个清单显示了合法使用模拟的示例。

The next listing shows an example of a legitimate use of mocks.

[事实]
公共无效成功_购买（）
{
    var mock = new Mock<IEmailGateway>();
    var sut = new CustomerController(mock.Object);

    bool isSuccess = sut.Purchase(
        customerId: 1, productId: 2, 数量: 5);

    断言.True(isSuccess);
    模拟。验证（                                   ❶ 
        x => x.SendReceipt(                        ❶ 
            "customer@email.com", "洗发水", 5),   ❶
        次.一次);                               ❶ 
}

[Fact]
public void Successful_purchase()
{
    var mock = new Mock<IEmailGateway>();
    var sut = new CustomerController(mock.Object);

    bool isSuccess = sut.Purchase(
        customerId: 1, productId: 2, quantity: 5);

    Assert.True(isSuccess);
    mock.Verify(                                   ❶
        x => x.SendReceipt(                        ❶
            "customer@email.com", "Shampoo", 5),   ❶
        Times.Once);                               ❶
}

请注意，该isSuccess标志也可以被外部客户端观察到，也需要验证。不过，这个标志不需要模拟；一个简单的值比较就足够了。

Note that the isSuccess flag is also observable by the external client and also needs verification. This flag doesn’t need mocking, though; a simple value comparison is enough.

Customer现在让我们看一个模拟和之间通信的测试Store。

Let’s now look at a test that mocks the communication between Customer and Store.

[事实]
public void Purchase_succeeds_when_enough_inventory()
{
    var storeMock = new Mock<IStore>();
    storeMock
        .Setup(x => x.HasEnoughInventory(Product.Shampoo, 5))
        .返回（真）；
    var customer = new Customer();

    布尔成功 = customer.Purchase(
        storeMock.Object, Product.Shampoo, 5);

    断言。真（成功）；
    storeMock.验证（
        x => x.RemoveInventory(Product.Shampoo, 5),
        次.Once);
}

[Fact]
public void Purchase_succeeds_when_enough_inventory()
{
    var storeMock = new Mock<IStore>();
    storeMock
        .Setup(x => x.HasEnoughInventory(Product.Shampoo, 5))
        .Returns(true);
    var customer = new Customer();

    bool success = customer.Purchase(
        storeMock.Object, Product.Shampoo, 5);

    Assert.True(success);
    storeMock.Verify(
        x => x.RemoveInventory(Product.Shampoo, 5),
        Times.Once);
}

CustomerController与 SMTP 服务之间的通信不同，从到 的RemoveInventory()方法调用不会跨越应用程序边界：调用者和接收者都驻留在应用程序内。此外，此方法既不是帮助客户端实现其目标的操作，也不是状态。这两个领域类的客户的目标是进行购买。与此目标有直接联系的仅有的两个成员是和。该方法发起购买，并显示购买完成后的系统状态。方法调用是实现客户目标的中间步骤：实现细节。CustomerStoreCustomerControllercustomer.Purchase()store.GetInventory()Purchase()GetInventory()RemoveInventory()

Unlike the communication between CustomerController and the SMTP service, the RemoveInventory() method call from Customer to Store doesn’t cross the application boundary: both the caller and the recipient reside inside the application. Also, this method is neither an operation nor a state that helps the client achieve its goals. The client of these two domain classes is CustomerController with the goal of making a purchase. The only two members that have an immediate connection to this goal are customer.Purchase() and store.GetInventory(). The Purchase() method initiates the purchase, and GetInventory() shows the state of the system after the purchase is completed. The RemoveInventory() method call is an intermediate step on the way to the client’s goal: an implementation detail.

5.4 经典单元测试与伦敦单元测试学派的再访

5.4  The classical vs. London schools of unit testing, revisited

表 5.2。单元测试的伦敦学派和经典学派之间的区别

Table 5.2. The differences between the London and classical schools of unit testing

让我快速回顾一下依赖类型（更多详细信息，请参阅第 2 章）：

Let me give you a quick refresher on types of dependencies (refer to chapter 2 for more details):

经典学派建议避免共享依赖关系，因为它们为测试提供了干扰彼此执行上下文的方法，从而防止这些测试并行运行。测试并行、顺序和以任何顺序运行的能力称为测试隔离。

The classical school recommends avoiding shared dependencies because they provide the means for tests to interfere with each other’s execution context and thus prevent those tests from running in parallel. The ability for tests to run in parallel, sequentially, and in any order is called test isolation.

如果共享依赖项不是进程外的，那么通过在每次测试运行时提供它的新实例，很容易避免在测试中重复使用它。在共享依赖项在进程外的情况下，测试变得更加复杂。您不能在每次测试执行之前实例化一个新的数据库或提供一个新的消息总线；那会大大减慢测试套件的速度。通常的方法是用测试替身（模拟和存根）替换此类依赖项。

If a shared dependency is not out-of-process, then it’s easy to avoid reusing it in tests by providing a new instance of it on each test run. In cases where the shared dependency is out-of-process, testing becomes more complicated. You can’t instantiate a new database or provision a new message bus before each test execution; that would drastically slow down the test suite. The usual approach is to replace such dependencies with test doubles — mocks and stubs.

不过，并非所有进程外依赖项都应该被模拟掉。如果只能通过您的应用程序访问进程外依赖项，那么与此类依赖项的通信不是系统可观察行为的一部分。无法从外部观察到的进程外依赖性实际上充当应用程序的一部分（图5.14）。

Not all out-of-process dependencies should be mocked out, though. If an out-of-process dependency is only accessible through your application, then communications with such a dependency are not part of your system’s observable behavior. An out-of-process dependency that can’t be observed externally, in effect, acts as part of your application (figure 5.14).

请记住，始终保持应用程序和外部系统之间的通信模式的要求源于维护向后兼容性的必要性。您必须保持应用程序与外部系统对话的方式。那是因为您不能在更改应用程序的同时更改这些外部系统；它们可能遵循不同的部署周期，或者您可能根本无法控制它们。

Remember, the requirement to always preserve the communication pattern between your application and external systems stems from the necessity to maintain backward compatibility. You have to maintain the way your application talks to external systems. That’s because you can’t change those external systems simultaneously with your application; they may follow a different deployment cycle, or you might simply not have control over them.

但是当您的应用程序充当外部系统的代理，并且没有客户端可以直接访问它时，向后兼容性要求就消失了。现在您可以将您的应用程序与这个外部系统一起部署，并且不会影响客户端。与此类系统的通信模式成为实现细节。

But when your application acts as a proxy to an external system, and no client can access it directly, the backward-compatibility requirement vanishes. Now you can deploy your application together with this external system, and it won’t affect the clients. The communication pattern with such a system becomes an implementation detail.

这里的一个很好的例子是应用程序数据库：一个仅供您的应用程序使用的数据库。没有外部系统可以访问该数据库。因此，您可以按照您喜欢的任何方式修改您的系统和应用程序数据库之间的通信模式，只要它不破坏现有功能即可。因为该数据库完全不为客户所见，您甚至可以用完全不同的存储机制替换它，而且没有人会注意到。

A good example here is an application database: a database that is used only by your application. No external system has access to this database. Therefore, you can modify the communication pattern between your system and the application database in any way you like, as long as it doesn’t break existing functionality. Because that database is completely hidden from the eyes of the clients, you can even replace it with an entirely different storage mechanism, and no one will notice.

对您可以完全控制的进程外依赖项使用模拟也会导致脆弱的测试。您不希望每次在数据库中拆分表或修改存储过程中的一个参数的类型时，测试都变成红色。数据库和您的应用程序必须被视为一个系统。

The use of mocks for out-of-process dependencies that you have a full control over also leads to brittle tests. You don’t want your tests to turn red every time you split a table in the database or modify the type of one of the parameters in a stored procedure. The database and your application must be treated as one system.

这显然提出了一个问题。在不影响反馈速度（良好单元测试的第三个属性）的情况下，您将如何测试具有这种依赖性的工作？您将在接下来的两章中深入了解这个主题。

This obviously poses an issue. How would you test the work with such a dependency without compromising the feedback speed, the third attribute of a good unit test? You’ll see this subject covered in depth in the following two chapters.

人们常说模拟是为了验证行为。在绝大多数情况下，他们没有。每个单独的类与相邻类交互以实现某个目标的方式与可观察到的行为无关；这是一个实现细节。

Mocks are often said to verify behavior. In the vast majority of cases, they don’t. The way each individual class interacts with neighboring classes in order to achieve some goal has nothing to do with observable behavior; it’s an implementation detail.

验证类之间的通信类似于试图通过测量大脑中的神经元在彼此之间传递的信号来推导一个人的行为。这种详细程度过于细化。重要的是可以追溯到客户目标的行为。当客户请求您提供帮助时，他们并不关心您大脑中的哪些神经元会亮起。唯一重要的是帮助本身——当然是由您以可靠和专业的方式提供的。只有当模拟验证跨越应用程序边界的交互并且只有当这些交互的副作用对外部世界可见时，模拟才与行为有关。

Verifying communications between classes is akin to trying to derive a person’s behavior by measuring the signals that neurons in the brain pass among each other. Such a level of detail is too granular. What matters is the behavior that can be traced back to the client goals. The client doesn’t care what neurons in your brain light up when they ask you to help. The only thing that matters is the help itself — provided by you in a reliable and professional fashion, of course. Mocks have something to do with behavior only when they verify interactions that cross the application boundary and only when the side effects of those interactions are visible to the external world.

5.5 总结

5.5  Summary

• 测试替身是一个包罗万象的术语，它描述了测试中各种非生产就绪的虚假依赖项。测试替身有五种变体——dummy、stub、spy、mock 和 fake——它们可以分为两种类型：mocks 和 stubs。间谍在功能上与模拟相同；假人和假人的作用与存根相同。

• Test double is an overarching term that describes all kinds of non-production-ready, fake dependencies in tests. There are five variations of test doubles — dummy, stub, spy, mock, and fake — that can be grouped in just two types: mocks and stubs. Spies are functionally the same as mocks; dummies and fakes serve the same role as stubs.

• Mocks 帮助模拟和检查结果交互：从 SUT 调用它的依赖项，改变这些依赖项的状态。存根有助于模拟传入的交互：调用 SUT 对其依赖项进行调用以获取输入数据。

• Mocks help emulate and examine outcoming interactions: calls from the SUT to its dependencies that change the state of those dependencies. Stubs help emulate incoming interactions: calls the SUT makes to its dependencies to get input data.

• 模拟（工具）是模拟库中的一个类，您可以使用它来创建模拟（测试替身）或存根。

• A mock (the tool) is a class from a mocking library that you can use to create a mock (the test double) or a stub.

• 断言与存根的交互会导致脆弱的测试。这样的交互并不对应最终结果；这是实现该结果的中间步骤，一个实现细节。

• Asserting interactions with stubs leads to fragile tests. Such an interaction doesn’t correspond to the end result; it’s an intermediate step on the way to that result, an implementation detail.

• 命令查询分离 (CQS) 原则指出每个方法都应该是命令或查询，但不能同时是两者。替代命令的测试替身是模拟的。替代查询的测试替身是存根。

• The command query separation (CQS) principle states that every method should be either a command or a query but not both. Test doubles that substitute commands are mocks. Test doubles that substitute queries are stubs.

• 所有生产代码都可以按两个维度分类：公共 API 与私有 API，以及可观察的行为与实现细节。代码公开性由访问修饰符控制，例如private、public和internal关键字。当代码满足以下要求之一时，它就是可观察行为的一部分（任何其他代码都是实现细节）：

  • 它公开了帮助客户端实现其目标之一的操作。操作是一种执行计算或产生副作用的方法。

  • 它公开了一种状态，可以帮助客户端实现其目标之一。状态是系统的当前状态。

• All production code can be categorized along two dimensions: public API versus private API, and observable behavior versus implementation details. Code publicity is controlled by access modifiers, such as private, public, and internal keywords. Code is part of observable behavior when it meets one of the following requirements (any other code is an implementation detail):

  • It exposes an operation that helps the client achieve one of its goals. An operation is a method that performs a calculation or incurs a side effect.

  • It exposes a state that helps the client achieve one of its goals. State is the current condition of the system.

• 设计良好的代码是其可观察行为与公共 API 一致并且其实现细节隐藏在私有 API 之后的代码。当代码的公共 API 超出可观察的行为范围时，代码会泄露实现细节。

• Well-designed code is code whose observable behavior coincides with the public API and whose implementation details are hidden behind the private API. A code leaks implementation details when its public API extends beyond the observable behavior.

• 封装是保护您的代码免受不变违规的行为。公开实现细节通常会破坏封装，因为客户可以使用实现细节来绕过代码的不变量。

• Encapsulation is the act of protecting your code against invariant violations. Exposing implementation details often entails a breach in encapsulation because clients can use implementation details to bypass the code’s invariants.

• 六边形架构是一组以六边形表示的交互应用程序。每个六边形由两层组成：域和应用程序服务。

• Hexagonal architecture is a set of interacting applications represented as hexagons. Each hexagon consists of two layers: domain and application services.

• 六边形架构强调三个重要方面：

  • 域和应用程序服务层之间的关注点分离。领域层应该负责业务逻辑，而应用服务应该协调领域层和外部应用之间的工作。

  • 从应用服务层到领域层的一种单向依赖流。领域层内的类应该只相互依赖；它们不应该依赖于应用服务层的类。

  • 外部应用程序通过应用程序服务层维护的公共接口连接到您的应用程序。没有人可以直接访问域层。

• Hexagonal architecture emphasizes three important aspects:

  • Separation of concerns between the domain and application services layers. The domain layer should be responsible for the business logic, while the application services should orchestrate the work between the domain layer and external applications.

  • A one-way flow of dependencies from the application services layer to the domain layer. Classes inside the domain layer should only depend on each other; they should not depend on classes from the application services layer.

  • External applications connect to your application through a common interface maintained by the application services layer. No one has a direct access to the domain layer.

• 六边形中的每一层都表现出可观察的行为，并包含自己的一组实现细节。

• Each layer in a hexagon exhibits observable behavior and contains its own set of implementation details.

• 应用程序中有两种类型的通信：系统内和系统间。系统内通信是应用程序内部类之间的通信。系统间通信是应用程序与外部应用程序对话的时候。

• There are two types of communications in an application: intra-system and inter-system. Intra-system communications are communications between classes inside the application. Inter-system communication is when the application talks to external applications.

• 系统内通信是实现细节。系统间通信是可观察行为的一部分，但只能通过您的应用程序访问的外部系统除外。与此类系统的交互也是实现细节，因为外部无法观察到由此产生的副作用。

• Intra-system communications are implementation details. Inter-system communications are part of observable behavior, with the exception of external systems that are accessible only through your application. Interactions with such systems are implementation details too, because the resulting side effects are not observed externally.

• 使用模拟断言系统内通信会导致脆弱的测试。仅当模拟用于系统间通信（跨越应用程序边界的通信）并且仅当外部世界可以看到这些通信的副作用时，模拟才是合法的。

• Using mocks to assert intra-system communications leads to fragile tests. Mocking is legitimate only when it’s used for inter-system communications — communications that cross the application boundary — and only when the side effects of those communications are visible to the external world.

6.2 比较三种单元测试风格

6.2  Comparing the three styles of unit testing

• 防止回归

• Protection against regressions

• 抵制重构

• Resistance to refactoring

• 快速反馈

• Fast feedback

• 可维护性

• Maintainability

让我们首先在防止回归和反馈速度属性方面比较这三种风格，因为这些属性在这个特定的比较中是最直接的。防止回归的指标不依赖于特定的测试方式。请注意，该指标是以下三个特征的产物：

Let’s first compare the three styles in terms of the protection against regressions and feedback speed attributes, as these attributes are the most straightforward in this particular comparison. The metric of protection against regressions doesn’t depend on a particular style of testing. Mind you, this metric is a product of the following three characteristics:

通常，您可以编写一个测试，根据您的喜好编写尽可能多或尽可能少的代码；没有特定的样式在这方面提供好处。代码的复杂性和领域重要性也是如此。唯一的例外是基于通信的风格：过度使用它会导致肤浅的测试，只验证一小部分代码并模拟其他所有内容。不过，这种肤浅并不是基于通信的测试的决定性特征，而是滥用这种技术的极端情况。

Generally, you can write a test that exercises as much or as little code as you like; no particular style provides a benefit in this area. The same is true for the code’s complexity and domain significance. The only exception is the communication-based style: overusing it can result in shallow tests that verify only a thin slice of code and mock out everything else. Such shallowness is not a definitive feature of communication-based testing, though, but rather is an extreme case of abusing this technique.

测试风格与测试的反馈速度之间几乎没有相关性。只要您的测试不触及进程外依赖性并因此停留在单元测试领域，所有样式都会产生大致相同执行速度的测试。基于通信的测试可能会稍差一些，因为模拟往往会在运行时引入额外的延迟。但是差别可以忽略不计，除非你有数以万计的这样的测试。

There’s little correlation between the styles of testing and the test’s feedback speed. As long as your tests don’t touch out-of-process dependencies and thus stay in the realm of unit testing, all styles produce tests of roughly equal speed of execution. Communication-based testing can be slightly worse because mocks tend to introduce additional latency at runtime. But the difference is negligible, unless you have tens of thousands of such tests.

当谈到重构阻力的指标时，情况就不同了。重构阻力是衡量在重构过程中产生了多少误报（误报）测试。反过来，误报是测试耦合到代码的实现细节而不是可观察到的行为的结果。

When it comes to the metric of resistance to refactoring, the situation is different. Resistance to refactoring is the measure of how many false positives (false alarms) tests generate during refactorings. False positives, in turn, are a result of tests coupling to code’s implementation details as opposed to observable behavior.

基于输出的测试提供了最好的防止误报的保护，因为生成的测试仅与被测方法耦合。此类测试与实现细节耦合的唯一方法是被测方法本身就是一个实现细节。

Output-based testing provides the best protection against false positives because the resulting tests couple only to the method under test. The only way for such tests to couple to implementation details is when the method under test is itself an implementation detail.

基于状态的测试通常更容易出现误报。除了被测方法之外，此类测试还适用于类的状态。从概率上讲，测试和生产代码之间的耦合度越大，该测试与泄漏的实现细节相关联的可能性就越大。基于状态的测试与更大的 API 表面相关联，因此将它们耦合到实现细节的机会也更高。

State-based testing is usually more prone to false positives. In addition to the method under test, such tests also work with the class’s state. Probabilistically speaking, the greater the coupling between the test and the production code, the greater the chance for this test to tie to a leaking implementation detail. State-based tests tie to a larger API surface, and hence the chances of coupling them to implementation details are also higher.

基于通信的测试最容易出现误报。你可能还记得第 5 章，绝大多数检查与测试替身交互的测试最终都很脆弱。与存根的交互总是如此——你永远不应该检查这样的交互。只有当它们验证跨越应用程序边界的交互并且只有当这些交互的副作用对外部世界可见时，Mock 才有用。如您所见，使用基于通信的测试需要格外谨慎，以保持对重构的适当抵抗。

Communication-based testing is the most vulnerable to false alarms. As you may remember from chapter 5, the vast majority of tests that check interactions with test doubles end up being brittle. This is always the case for interactions with stubs — you should never check such interactions. Mocks are fine only when they verify interactions that cross the application boundary and only when the side effects of those interactions are visible to the external world. As you can see, using communication-based testing requires extra prudence in order to maintain proper resistance to refactoring.

但就像肤浅一样，脆弱也不是基于沟通的风格的决定性特征。您可以通过维护适当的封装并将测试仅耦合到可观察的行为来将误报的数量减少到最低限度。不过，诚然，尽职调查的数量因单元测试的风格而异。

But just like shallowness, brittleness is not a definitive feature of the communication-based style, either. You can reduce the number of false positives to a minimum by maintaining proper encapsulation and coupling tests to observable behavior only. Admittedly, though, the amount of due diligence varies depending on the style of unit testing.

最后，可维护性指标与单元测试的风格高度相关；但是，与抵制重构不同，您无能为力。可维护性评估单元测试的维护成本，由以下两个特征定义：

Finally, the maintainability metric is highly correlated with the styles of unit testing; but, unlike with resistance to refactoring, there’s not much you can do to mitigate that. Maintainability evaluates the unit tests' maintenance costs and is defined by the following two characteristics:

较大的测试更难维护，因为它们更难掌握或在需要时更改。同样，直接使用一个或多个进程外依赖项（例如数据库）的测试更难维护，因为您需要花时间保持这些进程外依赖项的可操作性：重新启动数据库服务器，解决网络连接问题问题等等。

Larger tests are less maintainable because they are harder to grasp or change when needed. Similarly, a test that directly works with one or several out-of-process dependencies (such as the database) is less maintainable because you need to spend time keeping those out-of-process dependencies operational: rebooting the database server, resolving network connectivity issues, and so on.

[事实]
public void Adding_a_comment_to_an_article()
{
    var sut = new Article();
    var text = "注释文本";
    var author = "无名氏";
    var now = new DateTime(2019, 4, 1);

    sut.AddComment(文本, 作者, 现在);

    Assert.Equal(1, sut.Comments.Count);             ❶ 
    Assert.Equal(text, sut.Comments[0].Text);        ❶ 
    Assert.Equal(author, sut.Comments[0].Author);    ❶ 
    Assert.Equal(now, sut.Comments[0].DateCreated);  ❶ 
}

[Fact]
public void Adding_a_comment_to_an_article()
{
    var sut = new Article();
    var text = "Comment text";
    var author = "John Doe";
    var now = new DateTime(2019, 4, 1);

    sut.AddComment(text, author, now);

    Assert.Equal(1, sut.Comments.Count);             ❶
    Assert.Equal(text, sut.Comments[0].Text);        ❶
    Assert.Equal(author, sut.Comments[0].Author);    ❶
    Assert.Equal(now, sut.Comments[0].DateCreated);  ❶
}

[事实]
public void Adding_a_comment_to_an_article()
{
    var sut = new Article();
    var text = "注释文本";
    var author = "无名氏";
    var now = new DateTime(2019, 4, 1);

    sut.AddComment(文本, 作者, 现在);

    sut.ShouldContainNumberOfComments(1)   ❶ 
        .WithComment(文本、作者、现在);   ❶ 
}

[Fact]
public void Adding_a_comment_to_an_article()
{
    var sut = new Article();
    var text = "Comment text";
    var author = "John Doe";
    var now = new DateTime(2019, 4, 1);

    sut.AddComment(text, author, now);

    sut.ShouldContainNumberOfComments(1)   ❶
        .WithComment(text, author, now);   ❶
}

[事实]
public void Adding_a_comment_to_an_article()
{
    var sut = new Article();
    变种评论=新评论（
        “评论文字”，
        “无名氏”，
        新日期时间(2019, 4, 1));

    sut.AddComment(comment.Text, comment.Author, comment.DateCreated);

    sut.Comments.Should().BeEquivalentTo(评论);
}

[Fact]
public void Adding_a_comment_to_an_article()
{
    var sut = new Article();
    var comment = new Comment(
        "Comment text",
        "John Doe",
        new DateTime(2019, 4, 1));

    sut.AddComment(comment.Text, comment.Author, comment.DateCreated);

    sut.Comments.Should().BeEquivalentTo(comment);
}

现在让我们使用一个好的单元测试的属性来比较单元测试的风格。表6.1总结了比较结果。如第 6.2.1 节所述，所有三种风格在防止回归和反馈速度的指标上得分相同；因此，我在比较中省略了这些指标。

Let’s now compare the styles of unit testing using the attributes of a good unit test. Table 6.1 sums up the comparison results. As discussed in section 6.2.1, all three styles score equally with the metrics of protection against regressions and feedback speed; hence, I’m omitting these metrics from the comparison.

基于输出的测试显示了最好的结果。这种风格产生的测试很少与实现细节相结合，因此不需要太多的尽职调查来保持对重构的适当抵抗。此类测试也是最易于维护的，因为它们简洁且没有进程外依赖性。

Output-based testing shows the best results. This style produces tests that rarely couple to implementation details and thus don’t require much due diligence to maintain proper resistance to refactoring. Such tests are also the most maintainable due to their conciseness and lack of out-of-process dependencies.

基于状态和基于通信的测试在这两个指标上都更差。这些更有可能耦合到泄漏的实现细节，并且由于尺寸较大，它们还会产生更高的维护成本。

State-based and communication-based tests are worse on both metrics. These are more likely to couple to a leaking implementation detail, and they also incur higher maintenance costs due to being larger in size.

总是喜欢基于输出的测试胜过其他一切。不幸的是，说起来容易做起来难。这种单元测试风格仅适用于以函数式方式编写的代码，而对于大多数面向对象的编程语言来说，这种情况很少见。尽管如此，您仍然可以使用一些技术将更多测试转换为基于输出的风格。

Always prefer output-based testing over everything else. Unfortunately, it’s easier said than done. This style of unit testing is only applicable to code that is written in a functional way, which is rarely the case for most object-oriented programming languages. Still, there are techniques you can use to transition more of your tests toward the output-based style.

本章的其余部分展示了如何从基于状态和基于协作的测试过渡到基于输出的测试。转换要求您使代码更纯粹地发挥作用，这反过来又允许使用基于输出的测试，而不是基于状态或通信的测试。

The rest of this chapter shows how to transition from state-based and collaboration-based testing to output-based testing. The transition requires you to make your code more purely functional, which, in turn, enables the use of output-based tests instead of state- or communication-based ones.

6.3 理解功能架构

6.3  Understanding functional architecture

正如我在 6.1.1 节中提到的，基于输出的单元测试风格也称为功能测试。那是因为它需要使用函数式编程以纯函数式的方式编写底层生产代码。那么，什么是函数式编程？

As I mentioned in section 6.1.1, the output-based unit testing style is also known as functional. That’s because it requires the underlying production code to be written in a purely functional way, using functional programming. So, what is functional programming?

函数式编程是使用数学函数进行编程。数学函数（也称为纯函数）是一种没有任何隐藏输入或输出的函数（或方法）。数学函数的所有输入和输出都必须在其方法签名中明确表示，方法签名由方法的名称、参数和返回类型组成。对于给定的输入，无论调用多少次，数学函数都会产生相同的输出。

Functional programming is programming with mathematical functions. A mathematical function (also known as pure function) is a function (or method) that doesn’t have any hidden inputs or outputs. All inputs and outputs of a mathematical function must be explicitly expressed in its method signature, which consists of the method’s name, arguments, and return type. A mathematical function produces the same output for a given input regardless of how many times it is called.

我们以CalculateDiscount()清单6.1中的方法为例（为了方便，我将其复制到这里）：

Let’s take the CalculateDiscount() method from listing 6.1 as an example (I’m copying it here for convenience):

公共小数 CalculateDiscount(Product[] products)
{
    小数折扣 = products.Length * 0.01m;
    返回 Math.Min(折扣, 0.2m);
}

public decimal CalculateDiscount(Product[] products)
{
    decimal discount = products.Length * 0.01m;
    return Math.Min(discount, 0.2m);
}

此方法有一个输入（Product数组）和一个输出（decimal折扣），这两者都在方法的签名中明确表示。没有隐藏的输入或输出。这构成了CalculateDiscount()一个数学函数（图6.5）。

This method has one input (a Product array) and one output (the decimal discount), both of which are explicitly expressed in the method’s signature. There are no hidden inputs or outputs. This makes CalculateDiscount() a mathematical function (figure 6.5).

没有隐藏输入和输出的方法称为数学函数，因为这种方法符合数学中函数的定义。

Methods with no hidden inputs and outputs are called mathematical functions because such methods adhere to the definition of a function in mathematics.

图6.6显示了函数如何为每个输入数字xf(x) = x + 1找到对应的数字y。图6.7显示了使用与图6.6CalculateDiscount()中相同的符号的方法。

Figure 6.6 shows how for each input number x, function f(x) = x + 1 finds a corresponding number y. Figure 6.7 displays the CalculateDiscount() method using the same notation as in figure 6.6.

显式输入和输出使数学函数极易测试，因为生成的测试简短、简单且易于理解和维护。数学函数是唯一可以应用基于输出的测试的方法类型，它具有最好的可维护性和产生误报的可能性最低。

Explicit inputs and outputs make mathematical functions extremely testable because the resulting tests are short, simple, and easy to understand and maintain. Mathematical functions are the only type of methods where you can apply output-based testing, which has the best maintainability and the lowest chance of producing a false positive.

另一方面，隐藏的输入和输出会降低代码的可测试性（以及可读性）。此类隐藏输入和输出的类型包括：

On the other hand, hidden inputs and outputs make the code less testable (and less readable, too). Types of such hidden inputs and outputs include the following:

在确定方法是否为数学函数时，一个好的经验法则是查看是否可以在不更改程序行为的情况下用返回值替换对该方法的调用。用相应的值替换方法调用的能力称为引用透明性。看下面的方法，例如：

A good rule of thumb when determining whether a method is a mathematical function is to see if you can replace a call to that method with its return value without changing the program’s behavior. The ability to replace a method call with the corresponding value is known as referential transparency. Look at the following method, for example:

公共 int 增量（int x）
{
    返回 x + 1；
}

public int Increment(int x)
{
    return x + 1;
}

这个方法是一个数学函数。这两个语句是等价的：

This method is a mathematical function. These two statements are equivalent to each other:

int y =增量（4）；
整数 y = 5；

int y = Increment(4);
int y = 5;

另一方面，以下方法不是数学函数。您不能用返回值替换它，因为该返回值并不代表该方法的所有输出。在此示例中，隐藏输出是对字段的更改x（副作用）：

On the other hand, the following method is not a mathematical function. You can’t replace it with the return value because that return value doesn’t represent all of the method’s outputs. In this example, the hidden output is the change to field x (a side effect):

整数 x = 0;
公共整数增量（）
{
    x++;
    返回 x;
}

int x = 0;
public int Increment()
{
    x++;
    return x;
}

副作用是最普遍的隐藏输出类型。下面的清单显示了一种AddComment表面上看起来像数学函数但实际上不是数学函数的方法。图6.8以图形方式显示了该方法。

Side effects are the most prevalent type of hidden outputs. The following listing shows an AddComment method that looks like a mathematical function on the surface but actually isn’t one. Figure 6.8 shows the method graphically.

public Comment AddComment(字符串文本)
{
    var comment = new Comment(文本);
    _comments.Add(评论);            ❶
    回复评论；
}

public Comment AddComment(string text)
{
    var comment = new Comment(text);
    _comments.Add(comment);            ❶
    return comment;
}

当然，您无法创建不会产生任何副作用的应用程序。这样的应用是不切实际的。毕竟，副作用是您创建所有应用程序的目的：更新用户信息、向购物车添加新的订单行等等。

You can’t create an application that doesn’t incur any side effects whatsoever, of course. Such an application would be impractical. After all, side effects are what you create all applications for: updating the user’s information, adding a new order line to the shopping cart, and so on.

函数式编程的目标不是完全消除副作用，而是在处理业务逻辑的代码和产生副作用的代码之间引入分离。这两个职责本身就足够复杂了；从长远来看，将它们混合在一起会增加复杂性并阻碍代码的可维护性。这就是功能架构发挥作用的地方。它通过将副作用推到业务操作的边缘来将业务逻辑与副作用分开。

The goal of functional programming is not to eliminate side effects altogether but rather to introduce a separation between code that handles business logic and code that incurs side effects. These two responsibilities are complex enough on their own; mixing them together multiplies the complexity and hinders code maintainability in the long run. This is where functional architecture comes into play. It separates business logic from side effects by pushing those side effects to the edges of a business operation.